Agentic Cloud Governance Center:Éléments de contrôle pris en charge (Modèle 3.0)

Catégorie

Élément de vérification

Description

Description de la correction rapide

Aide à la décision assistée

Gestion des identités du personnel

L'authentification multifacteur (MFA) n'est pas activée pour le compte Alibaba Cloud

Activez l'authentification multifacteur (MFA) sur votre compte Alibaba Cloud pour bénéficier d'une couche de sécurité supplémentaire. Une configuration sans MFA est considérée comme non conforme.

Non pris en charge.

Non

Gestion des identités du personnel

Un utilisateur Resource Access Management (RAM) dispose à la fois d'un accès à la console et d'une AccessKey active

Selon le principe du moindre privilège, un utilisateur RAM ne doit pas cumuler accès à la console et AccessKey. Cette situation rend la configuration non conforme. Si l'authentification unique (SSO) est activée pour le compte, le paramètre de connexion à la console est ignoré. Toutefois, la configuration reste non conforme si l'utilisateur possède une AccessKey et s'est connecté à la console au cours des 7 derniers jours.

Cette correction désactive la connexion à la console pour l'utilisateur RAM sélectionné. Avant d'appliquer cette correction, confirmez que l'utilisateur n'a plus besoin d'accéder à la console.

Oui

Gestion des identités du personnel

L'authentification MFA n'est pas activée pour un utilisateur RAM

L'authentification MFA renforce la sécurité des utilisateurs RAM. Si un utilisateur RAM peut se connecter à la console mais que l'MFA n'est pas activée, la configuration est non conforme.

Non pris en charge.

Oui

Gestion des identités du personnel

RAM n'est pas utilisé pour la gestion des identités

Le compte Alibaba Cloud dispose de permissions étendues dont la compromission présenterait un risque de sécurité élevé. Utilisez des identités RAM pour les opérations quotidiennes. L'absence d'identités RAM rend la configuration non conforme.

Non pris en charge.

Non

Gestion des identités du personnel

Un utilisateur RAM ne respecte pas les exigences de complexité du mot de passe

L'application de politiques de mot de passe strictes réduit les risques d'attaques par bourrage d'identifiants et par force brute. La configuration est non conforme si les exigences relatives à la longueur, aux types de caractères, à l'expiration, à l'historique ou aux limites de tentatives ne sont pas appliquées.

Cette correction met à jour les paramètres de complexité des mots de passe dans RAM. Les paramètres configurés sont les suivants : longueur minimale de 8 caractères, exigence d'au moins trois types de caractères, durée de validité maximale de 90 jours et limite de cinq tentatives de connexion par heure. Ces valeurs correspondent aux recommandations des meilleures pratiques. Vous pouvez ajuster ces paramètres pour appliquer des exigences plus strictes. Une fois la configuration terminée, les paramètres s'appliquent à tous les utilisateurs RAM.

Non

Gestion des identités du personnel

Le compte Alibaba Cloud s'est connecté à la console au cours des 90 derniers jours

Le compte Alibaba Cloud dispose de permissions étendues qui ne peuvent pas être restreintes par des conditions telles que l'IP source ou l'heure. La compromission de ce compte présenterait un risque de sécurité élevé. Si le compte a été utilisé pour se connecter à la console au cours des 90 derniers jours, la configuration est non conforme.

Non pris en charge.

Non

Gestion des identités du personnel

Un utilisateur RAM inactif existe

Les utilisateurs RAM disposant d'un accès à la console utilisent des mots de passe pour se connecter. Plus un mot de passe existe longtemps, plus le risque d'exposition augmente. Si un utilisateur RAM ne s'est pas connecté depuis plus de 90 jours, la configuration est non conforme.

Cette correction désactive la connexion à la console pour l'utilisateur RAM sélectionné. Avant d'appliquer cette correction, confirmez que l'utilisateur n'a plus besoin d'accéder à la console. Remarque : Si le SSO est activé, la désactivation de la connexion à la console ne supprime pas l'utilisateur de la liste des resources. Pour effacer l'alerte, vous devez supprimer l'utilisateur RAM.

Oui

Gestion des identités du personnel

Le SSO RAM n'est pas activé pour la connexion à la console

Utilisez le SSO pour gérer centralisément les identités des utilisateurs et réduire les risques de sécurité. La configuration est non conforme si le SSO RAM n'est pas configuré ou si aucune connexion SSO n'a eu lieu au cours des 30 derniers jours.

Non pris en charge.

Non

Gestion des identités du personnel

La gestion unifiée des identités multi-comptes est recommandée

Utilisez Cloud SSO pour gérer tous les utilisateurs de votre organisation. Configurez votre fournisseur d'identité (IdP) d'entreprise pour Alibaba Cloud SSO et définissez des permissions d'accès uniformes pour les comptes membres de votre Resource Directory (RD). Si Cloud SSO n'a pas été utilisé depuis plus de 90 jours, la configuration est non conforme.

Non pris en charge.

Non

Gestion des identités du personnel

La synchronisation des utilisateurs SCIM RAM n'est pas activée

System for Cross-domain Identity Management (SCIM) synchronise les identités d'entreprise avec Alibaba Cloud, ce qui élimine le besoin de créer manuellement des utilisateurs. La configuration est non conforme si SCIM n'est pas configuré ou si les utilisateurs synchronisés ne se sont pas connectés depuis deux mois.

Non pris en charge.

Non

Gestion des identités programmatiques

Une AccessKey active existe pour le compte Alibaba Cloud

Une AccessKey associée à un compte Alibaba Cloud accorde des permissions complètes sur ce compte. Elle ne peut pas être restreinte par des conditions telles que l'IP source ou l'heure. La fuite de cette AccessKey présenterait un risque de sécurité élevé. Si une AccessKey active existe pour le compte, la configuration est non conforme.

Cette correction désactive l'AccessKey sélectionnée pour le compte Alibaba Cloud. Avant d'appliquer cette correction, confirmez que l'AccessKey n'est utilisée par aucun programme ou application. La désactivation de l'AccessKey améliore partiellement le score de sécurité, mais l'alerte persiste jusqu'à la suppression de l'AccessKey. Remarque : Seul le compte Alibaba Cloud peut effectuer cette correction. Toute tentative effectuée via un utilisateur RAM ou un rôle RAM échouera.

Oui

Gestion des identités programmatiques

Un utilisateur RAM possède deux AccessKeys actives

Un utilisateur RAM disposant de deux AccessKeys actives ne peut pas les faire tourner, ce qui accroît les risques de sécurité. Si un utilisateur RAM possède deux AccessKeys actives, la configuration est non conforme.

Cette correction désactive l'AccessKey sélectionnée pour l'utilisateur RAM. Avant d'appliquer cette correction, confirmez que l'AccessKey n'est utilisée par aucun programme ou application.

Oui

Gestion des identités programmatiques

Une AccessKey exposée et non traitée existe

Si une AccessKey est exposée, des attaquants peuvent l'utiliser pour accéder à vos resources et données. Si un événement d'exposition d'AccessKey non traité existe, la configuration est non conforme.

Non pris en charge.

Non

Gestion des identités programmatiques

Une clé KMS est programmée pour suppression (nouveau dans le modèle 3.0)

Lorsqu'une clé maître client (CMK) est supprimée, elle ne peut pas être récupérée. Les données chiffrées avec la CMK et ses clés de données associées deviennent définitivement indéchiffrables. Pour éviter toute suppression accidentelle et toute interruption de service, assurez-vous que les CMK actives ne sont pas programmées pour suppression. Si une CMK est programmée pour suppression, la configuration est non conforme.

Cette correction annule la suppression programmée de la clé KMS sélectionnée. Le statut de la clé passe de « Programmée pour suppression » à « Activée ». Une fois activée, la clé peut être utilisée pour chiffrer et déchiffrer des données, et les frais de facturation standard s'appliquent.

Non

Gestion des identités programmatiques

Une AccessKey n'a pas fait l'objet d'une rotation régulière

La rotation régulière des AccessKeys réduit leur temps d'exposition et diminue le risque de fuites. Si l'AccessKey d'un utilisateur RAM est utilisée depuis plus de 365 jours, la configuration est non conforme.

Non pris en charge.

Non

Gestion des identités programmatiques

Une AccessKey inactive existe

L'AccessKey d'un utilisateur RAM permet l'accès API à Alibaba Cloud. Plus une AccessKey reste exposée longtemps, plus le risque de fuite augmente. Si une AccessKey n'a pas été utilisée depuis plus de 365 jours, la configuration est non conforme.

Cette correction désactive l'AccessKey sélectionnée pour l'utilisateur RAM. Avant d'appliquer cette correction, confirmez que l'AccessKey n'est utilisée par aucun programme ou application. La désactivation de l'AccessKey améliore partiellement le score de sécurité, mais l'alerte persiste jusqu'à la suppression de l'AccessKey.

Oui

Gestion des identités programmatiques

L'authentification par mot de passe n'est pas activée sur une instance Redis (nouveau dans le modèle 3.0)

Si une instance Redis située dans un VPC n'a pas l'authentification par mot de passe activée ou si ses paramètres de sécurité sont mal configurés, cela peut entraîner des fuites de données, des actions malveillantes non autorisées, des problèmes de sécurité réseau ou des interruptions de service. Si l'authentification par mot de passe est désactivée pour une instance Redis dans un VPC, la configuration est non conforme.

Non pris en charge.

Non

Gestion des identités programmatiques

L'accès programmatique n'utilise pas de solution sans AccessKey

La configuration est non conforme si les instances ECS n'ont pas de rôles d'instance, si les clusters ACK n'ont pas le plug-in RRSA activé, ou si les services Function Compute n'ont pas de rôles de service.

Non pris en charge.

Non

Gestion des identités programmatiques

Une instance ECS n'utilise pas le Metadata Service renforcé (V2)

Utilisez le Metadata Service renforcé (V2) pour les instances ECS afin d'éviter les fuites potentielles de jetons Security Token Service (STS) pouvant survenir avec la version V1. Si une instance ECS utilise la version V1, la configuration est non conforme. Pour résoudre ce problème, mettez à niveau le Metadata Service vers la version V2.

Non pris en charge.

Non

Gestion des permissions

Trop d'identités RAM possèdent la permission AdministratorAccess

Selon le principe du moindre privilège, limitez le nombre d'identités RAM auxquelles la permission AdministratorAccess est accordée. Cette permission permet un contrôle total sur toutes les resources ; l'accorder à trop d'identités augmente l'impact d'une éventuelle fuite d'identité. La configuration est conforme si trois identités RAM ou moins possèdent la permission AdministratorAccess.

Cette correction remplace la permission AdministratorAccess par la permission PowerUserAccess. PowerUserAccess accorde un accès complet aux services et resources Alibaba Cloud, mais n'inclut pas les permissions nécessaires pour gérer les identités RAM, Resource Directory, les resources partagées ou les informations financières du compte. La correction analyse les journaux d'audit des permissions et remplace automatiquement la permission AdministratorAccess par PowerUserAccess pour les identités administrateur inutilisées.

Non

Gestion des permissions

Trop d'identités RAM non administratrices possèdent des permissions de facturation à haut risque

Selon le principe du moindre privilège, limitez les permissions de facturation à haut risque. Des permissions telles que `bss:*`, `bssapi:*`, `bss:PayOrder`, `bss:Modify*`, `bss:Create*`, `bss:*Order*` et `bss:Delete*` permettent aux utilisateurs de modifier les commandes, les factures, les contrats, les relevés, les transactions et les retraits. Une mauvaise gestion de ces permissions peut entraîner des pertes financières. La configuration est conforme si trois identités RAM non administratrices ou moins possèdent ces permissions.

Non pris en charge.

Non

Gestion des permissions

Trop d'identités RAM non administratrices possèdent des permissions à privilèges élevés

Selon le principe du moindre privilège, limitez les permissions à privilèges élevés. Celles-ci permettent aux identités RAM d'élever leurs propres permissions ou celles d'autres utilisateurs. Une utilisation abusive peut compromettre la sécurité et la confidentialité de vos resources. La configuration est conforme si trois identités RAM non administratrices ou moins possèdent des permissions à privilèges élevés. La liste complète de ces permissions est disponible dans la documentation.

Non pris en charge.

Non

Gestion des permissions

Une identité RAM non administratrice possède des permissions de déchiffrement pour toutes les clés KMS

KMS vous permet de contrôler qui peut utiliser vos clés et accéder à vos données chiffrées. Les politiques RAM définissent les actions que les identités (utilisateurs, groupes ou rôles) peuvent effectuer sur des resources spécifiques. Suivez les meilleures pratiques de sécurité en n'accordant que les permissions nécessaires et en restreignant l'accès à des clés spécifiques. Accorder la permission `kms:Decrypt` pour toutes les clés crée un risque de sécurité excessif. Identifiez plutôt l'ensemble minimal de clés requis et n'accordez l'accès qu'à celles-ci. Par exemple, autorisez l'action `kms:Decrypt` uniquement sur des clés spécifiques dans des régions spécifiques. Cette approche minimise le risque d'exposition des données.

Non pris en charge.

Non

Gestion des permissions

Une identité RAM possède des permissions inactives au niveau du produit

Les permissions au niveau du produit sont considérées comme inactives si elles ne sont pas utilisées pendant une période donnée après leur attribution. Cela peut résulter d'un changement de rôle ou de permissions initiales trop larges. Il est recommandé de révoquer les permissions inactives pour obtenir une autorisation granulaire. Si une identité RAM conserve des permissions inactives au niveau du produit pendant 180 jours, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Gestion des permissions

Une identité RAM possède des permissions inactives pour des opérations à haut risque

Les permissions pour des opérations à haut risque, telles que la création d'utilisateurs RAM, sont considérées comme inactives si elles ne sont pas utilisées pendant une période donnée après leur attribution. Cela peut résulter d'un changement de rôle ou de permissions initiales trop larges. Il est recommandé de révoquer rapidement les permissions inactives à haut risque pour prévenir les incidents de sécurité. Si une identité RAM conserve de telles permissions inactives pendant 180 jours, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Gestion des permissions

Toutes les identités RAM possèdent la permission AdministratorAccess

Selon le principe du moindre privilège, évitez d'accorder la permission AdministratorAccess à toutes les identités RAM afin de limiter l'impact d'une éventuelle fuite d'identité. La configuration est conforme si au moins une identité RAM possède des permissions non administratrices.

Cette correction remplace la permission AdministratorAccess par la permission PowerUserAccess. PowerUserAccess accorde un accès complet aux services et resources Alibaba Cloud, mais n'inclut pas les permissions nécessaires pour gérer les identités RAM, Resource Directory, les resources partagées ou les informations financières du compte. La correction analyse les journaux d'audit des permissions et remplace automatiquement la permission AdministratorAccess par PowerUserAccess pour les identités administrateur inutilisées.

Non

Gestion des permissions

Access Analyzer n'est pas utilisé pour la gestion des permissions (nouveau dans le modèle 3.0)

Access Analyzer vous aide à identifier les resources partagées avec des comptes externes et détecte les partages inattendus pour réduire les risques de sécurité. Il identifie également les identités disposant de permissions excessives et génère des rapports d'analyse.

Non pris en charge.

Non

Gestion des permissions

L'utilisation de politiques de contrôle pour la protection des limites multi-comptes est recommandée

Les politiques de contrôle de Resource Directory permettent aux organisations de restreindre les services cloud et les opérations accessibles aux comptes membres. Cela facilite la gestion centralisée des limites de permissions et garantit la conformité aux normes de sécurité. La configuration est non conforme si aucune politique de contrôle personnalisée n'est créée et attachée à un dossier Resource Directory ou à un compte membre.

Non pris en charge.

Non

Gestion des permissions

Aucun utilisateur RAM n'hérite de permissions d'un groupe d'utilisateurs RAM

Par défaut, les utilisateurs, groupes et rôles RAM ne peuvent accéder à aucune resource. Vous devez accorder des permissions via des politiques RAM. Pour simplifier la gestion et réduire le risque d'extension accidentelle des permissions, appliquez les politiques à des groupes ou des rôles plutôt qu'à des utilisateurs individuels. La configuration est conforme aux meilleures pratiques si au moins un utilisateur RAM hérite de permissions d'un groupe d'utilisateurs RAM.

Non pris en charge.

Non

Collecte et archivage des journaux

Les journaux ActionTrail ne sont pas conservés à long terme

La configuration est non conforme si aucune piste n'est créée, ou si une piste existante n'archive pas les événements de toutes les régions, n'archive pas toutes les opérations de lecture et d'écriture, ou conserve les journaux pendant moins de 180 jours.

Cette correction améliore les paramètres d'une piste existante pour inclure tous les événements de gestion en lecture et écriture ainsi que les événements de toutes les régions. Vous devez sélectionner au moins une piste existante à mettre à jour. Les nouveaux événements générés après l'application de la correction sont livrés au stockage de destination de la piste. Les événements historiques ne sont pas affectés.

Non

Collecte et archivage des journaux

La collecte des journaux n'est pas configurée pour EDAS (nouveau dans le modèle 3.0)

Alibaba Cloud Enterprise Distributed Application Service (EDAS) s'intègre à Simple Log Service (SLS) pour collecter les journaux d'applications et les journaux stdout des conteneurs des clusters Kubernetes à des fins de requête et d'analyse. Si la collecte des journaux n'est pas configurée pour EDAS, la configuration est non conforme.

Non pris en charge.

Non

Collecte et archivage des journaux

La requête de journaux en temps réel n'est pas activée sur un bucket OSS (nouveau dans le modèle 3.0)

La fonctionnalité de journalisation en temps réel d'OSS enregistre les accès aux buckets à des fins d'audit, de surveillance et d'analyse. La configuration est non conforme si la journalisation en temps réel est désactivée ou si la période de conservation des journaux est inférieure ou égale à 180 jours.

Non pris en charge.

Non

Collecte et archivage des journaux

La livraison des journaux n'est pas activée sur un bucket OSS (nouveau dans le modèle 3.0)

Les journaux d'accès OSS peuvent générer un volume important de données. La fonctionnalité de livraison des journaux écrit des fichiers horaires dans un bucket spécifié selon une convention de nommage fixe. Analysez les journaux livrés à l'aide de Simple Log Service ou de clusters Spark. La configuration est conforme si la livraison des journaux est activée pour un bucket OSS.

Non pris en charge.

Non

Collecte et archivage des journaux

Aucune tâche de livraison de journaux n'est configurée pour un site ESA

Cette vérification confirme qu'au moins un type de journal est configuré pour le site afin de fournir des journaux d'accès en temps réel pour la surveillance, l'analyse et l'optimisation de la diffusion de contenu. Si aucun type de journal n'est configuré, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Collecte et archivage des journaux

Les journaux Cloud Firewall ne sont pas collectés et stockés pendant au moins 180 jours

Cloud Firewall journalise automatiquement tout le trafic et fournit des pages d'audit visualisées pour les événements d'attaque, les détails du trafic et les journaux d'opérations. La période de conservation par défaut est de 7 jours. Pour des raisons de conformité et de sécurité renforcée, stockez les journaux pendant au moins 180 jours. Si vous avez souscrit à une édition par abonnement de Cloud Firewall mais ne stockez pas les journaux pendant au moins 180 jours, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Cette correction active l'analyse des journaux pour Cloud Firewall et définit la période de conservation. Pour se conformer aux réglementations sur la protection des données et la sécurité réseau, cette période doit être d'au moins 180 jours. Une fois cette fonctionnalité activée, Cloud Firewall crée un Project et un Logstore dédiés pour stocker tous les journaux. Des frais s'appliquent en fonction de la durée de conservation et de la capacité de stockage. Détails de facturation.

Non

Collecte et archivage des journaux

L'agrégation centralisée des journaux d'opérations multi-comptes est recommandée

ActionTrail conserve les événements pendant 90 jours par défaut. La création de pistes permet de conserver les enregistrements d'opérations à des fins de conformité. Les pistes multi-comptes permettent aux administrateurs de suivre et d'auditer centralisément les journaux sur plusieurs comptes. Si aucune piste multi-comptes n'existe, la configuration est non conforme.

Non pris en charge.

Non

Collecte et archivage des journaux

L'activation de la collecte centralisée des journaux pour les environnements multi-comptes est recommandée

Si le service approuvé pour l'audit des journaux Simple Log Service (SLS) est désactivé, la configuration est non conforme.

Non pris en charge.

Non

Vérifications de conformité

Des resources cloud sont non conformes

Si les règles Cloud Config détectent une non-conformité et que le taux de resources conformes est inférieur à 100 %, la configuration est non conforme.

Non pris en charge.

Non

Vérifications de conformité

Cloud Config n'est pas activé

Si Cloud Config n'est pas activé, la configuration est non conforme.

Non pris en charge.

Non

Vérifications de conformité

Les règles de conformité Cloud Config ne sont pas activées

Si les règles de conformité Cloud Config ne sont pas activées, la configuration est non conforme.

Non pris en charge.

Non

Vérifications de conformité

Les règles de conformité Cloud Config ne couvrent pas toutes les resources cloud

Si la couverture des règles est inférieure à 100 %, la configuration est non conforme.

Non pris en charge.

Non

Vérifications de conformité

L'activation de vérifications de configuration unifiées pour les environnements multi-comptes est recommandée

La configuration est non conforme si l'une des conditions suivantes n'est pas remplie : 1. Un groupe de comptes existe et des règles y sont configurées. 2. Les événements de non-conformité sont livrés à SLS.

Non pris en charge.

Non

Vérifications de conformité

Les données de vérification de conformité ne sont pas récupérées régulièrement

Si Cloud Config ne livre pas d'événements de non-conformité ou si les résultats n'ont pas été consultés au cours des 7 derniers jours, la configuration est non conforme.

Cette correction crée une tâche de livraison de données de resources dans le compte actuel. Elle livre des instantanés de configuration et de conformité ainsi que des modifications à SLS, OSS ou MNS dans un compte Alibaba Cloud spécifié pour la persistance et les notifications. Les tâches de livraison sont gratuites, mais des frais standards de livraison de données s'appliquent. Détails de facturation.

Non

Vérifications de conformité

La livraison des modifications de resources ou des instantanés n'est pas configurée

Si Cloud Config ne livre pas les modifications de resources ou les instantanés, la configuration est non conforme.

Cette correction crée une tâche de livraison de données de resources dans le compte actuel. Elle livre des instantanés de configuration et de conformité ainsi que des modifications à SLS, OSS ou MNS dans un compte Alibaba Cloud spécifié pour la persistance et les notifications. Les tâches de livraison sont gratuites, mais des frais standards de livraison de données s'appliquent. Détails de facturation.

Non

Protection des resources de calcul

Des problèmes de référence de sécurité de l'hôte nécessitent une correction

Les virus et les pirates exploitent les faiblesses de configuration des serveurs pour voler des données ou installer des portes dérobées. Les vérifications de référence évaluent les configurations du système d'exploitation, des bases de données, des logiciels et des conteneurs. La correction des problèmes de référence renforce la sécurité, réduit les risques d'intrusion et aide à répondre aux exigences de conformité. Si des références non corrigées existent, la configuration est non conforme.

Non pris en charge.

Non

Protection des resources de calcul

Des vulnérabilités nécessitent une correction

La gestion des vulnérabilités est un processus continu et proactif. Elle protège les systèmes, les réseaux et les applications contre les cyberattaques et les violations de données. Une correction rapide prévient les attaques et minimise les dommages. Si des vulnérabilités non corrigées existent, la configuration est non conforme.

Non pris en charge.

Non

Protection des resources de calcul

La protection contre les ransomwares n'est pas activée

Les ransomwares chiffrent les données métier, ce qui peut provoquer des interruptions de service, des fuites de données et des pertes de données. Configurer la protection contre les ransomwares réduit ces risques. Si la protection contre les ransomwares est achetée mais qu'aucune politique de protection n'est créée, la configuration est non conforme.

Non pris en charge.

Non

Protection des resources de calcul

L'antivirus n'est pas activé

Les analyses antivirus éliminent les menaces malveillantes, notamment les ransomwares, les chevaux de Troie DDoS, les logiciels malveillants de minage, les portes dérobées et les vers. Si l'antivirus est acheté pour Security Center (édition Enterprise ou Ultimate) mais qu'aucune politique d'analyse périodique n'est configurée, la configuration est non conforme.

Cette correction configure l'analyse antivirale périodique dans Security Center. Après l'application de la correction, l'analyse s'exécute sur tous les serveurs éligibles selon l'intervalle et la fenêtre temporelle configurés. Les alertes virales apparaissent dans le module d'alertes de sécurité. Traitez-les rapidement pour garantir la sécurité des serveurs.

Non

Protection des resources de calcul

L'analyse des images de conteneurs n'est pas configurée

Les images présentant des vulnérabilités système ou applicatives, ou celles remplacées par des versions malveillantes, peuvent introduire des risques. L'analyse des images dans les registres permet aux équipes de sécurité de transmettre les résultats aux développeurs pour correction. Si l'analyse d'images est achetée mais qu'aucune étendue d'analyse n'est configurée, la configuration est non conforme.

Non pris en charge.

Non

Protection de l'exécution des applications

Les règles gérées WAF ne sont pas configurées pour un site ESA

Cette vérification confirme que les sites disposent de règles gérées WAF pour mieux protéger les applications web et API. Si aucune règle gérée n'est configurée, la configuration n'est pas conforme aux meilleures pratiques de protection des applications web.

Les règles gérées sont des règles intelligentes intégrées pour ESA. Elles protègent contre les attaques OWASP et les vulnérabilités émergentes de l'origine. Cette correction active l'ensemble de règles gérées pour le site ESA sélectionné. La disponibilité des règles varie selon l'édition (fonctionnalités prises en charge par édition).

Non

Protection de l'exécution des applications

Les règles personnalisées WAF ne sont pas configurées pour un site ESA

Cette vérification confirme que les sites disposent de règles personnalisées WAF pour détecter et atténuer les requêtes malveillantes. Si aucune règle personnalisée n'est configurée, la configuration n'est pas conforme aux meilleures pratiques de protection des applications web.

Non pris en charge.

Non

Protection de l'exécution des applications

Les configurations de protection des applications ne sont pas créées

La détection et la protection lors de l'exécution défendent les applications Java contre les vulnérabilités zero-day. Si la protection des applications est achetée mais qu'aucune configuration ou groupe n'existe, la configuration est non conforme.

Non pris en charge.

Non

Protection de l'exécution des applications

Web Tamper Protection n'est pas activé

Web Tamper Protection surveille en temps réel les répertoires ou fichiers de sites web et restaure le contenu altéré à partir de sauvegardes. Il empêche l'injection de contenu illégal et garantit la disponibilité du site. Si Web Tamper Protection est acheté mais qu'aucun serveur n'est lié, la configuration est non conforme.

Non pris en charge.

Non

Réponse aux attaques réseau

Anti-DDoS Pro ou Anti-DDoS Premium dépasse les seuils de défense (nouveau dans le modèle 3.0)

Si le trafic d'attaque dépasse la bande passante de protection d'une instance Anti-DDoS, l'instance passe en mode trou noir. Tout le trafic routé via celle-ci est bloqué, rendant les services inaccessibles. Si le statut IP de l'instance Anti-DDoS est « Trou noir activé », la configuration est non conforme.

Non pris en charge.

Non

Réponse aux attaques réseau

Une instance ECS dépasse les seuils de défense DDoS (nouveau dans le modèle 3.0)

Si une instance ECS subit des attaques DDoS volumineuses dépassant sa bande passante de défense, la politique de trou noir d'Alibaba Cloud bloque le trafic entre l'instance et Internet pour éviter des dommages plus étendus et protéger d'autres actifs. Si une instance ECS dotée d'une adresse IP publique ouverte présente un statut de protection DDoS « Trou noir activé », la configuration est non conforme.

Non pris en charge.

Non

Réponse aux attaques réseau

Une EIP dépasse les seuils de défense DDoS (nouveau dans le modèle 3.0)

Si une EIP subit des attaques DDoS volumineuses dépassant sa bande passante de défense, la politique de trou noir d'Alibaba Cloud bloque le trafic entre l'EIP et Internet pour éviter des dommages plus étendus et protéger d'autres actifs. Si le statut de protection DDoS d'une EIP est « Trou noir activé », la configuration est non conforme.

Non pris en charge.

Non

Réponse aux attaques réseau

Une instance SLB dépasse les seuils de défense DDoS (nouveau dans le modèle 3.0)

Si une instance SLB subit des attaques DDoS volumineuses dépassant sa bande passante de défense, la politique de trou noir d'Alibaba Cloud bloque le trafic entre l'instance et Internet pour éviter des dommages plus étendus et protéger d'autres actifs. Si le statut de protection DDoS d'une instance SLB est « Trou noir activé », la configuration est non conforme.

Non pris en charge.

Non

Réponse aux attaques réseau

Aucun objet protégé n'est ajouté à la protection DDoS native

Après avoir acheté Native DDoS Protection ou des instances Anti-DDoS, ajoutez des actifs IP public en tant qu'objets protégés pour activer la protection DDoS. Sans cette étape, la protection est inefficace et les coûts sont gaspillés.

Non pris en charge.

Non

Réponse aux attaques réseau

La protection intelligente basée sur l'IA pour les sites web est définie sur le mode Strict

La protection intelligente basée sur l'IA améliore la sécurité des sites web. Cependant, le mode Strict peut provoquer des faux positifs. N'utilisez le mode Strict que pour les sites web présentant de mauvaises performances ou une protection inadéquate. Remarque : Les domaines de sites web disposent d'une protection intégrée contre les attaques de couche 4. Pour la plupart des sites web, utilisez le mode Normal pour équilibrer protection et continuité d'activité.

Cette correction définit la protection intelligente basée sur l'IA sur le mode Blocage avec une sévérité Normale. Anti-DDoS Proxy générera automatiquement des règles de contrôle d'accès précises et se défendra intelligemment contre les attaques malveillantes lorsque des menaces seront détectées.

Non

Contrôle d'accès réseau

Une instance ECS n'est pas interdite de liaison à une adresse IP publique

Pour réduire le risque d'attaques, évitez d'exposer directement les instances ECS à l'Internet public. Utilisez plutôt NAT Gateway ou Server Load Balancer. Si une instance ECS est liée à une adresse IP publique, la configuration est non conforme.

Non pris en charge.

Non

Contrôle d'accès réseau

Une instance Elasticsearch a un endpoint public activé et aucune liste d'autorisation d'adresses IP

Exposer Elasticsearch à l'Internet public pose des risques de sécurité. Le service devient visible par les attaquants et peut subir des fuites ou des destructions de données en l'absence de contrôles d'accès appropriés. Il est recommandé d'autoriser l'accès uniquement depuis les réseaux internes VPC et de configurer des listes d'autorisation IP appropriées. Si un endpoint public est activé, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Contrôle d'accès réseau

Le service Kibana d'une instance Elasticsearch a un endpoint public activé et aucune liste d'autorisation d'adresses IP

Exposer Kibana à l'Internet public pose des risques de sécurité. Le service devient visible par les attaquants et peut subir des fuites ou des destructions de données en l'absence de contrôles d'accès appropriés. Il est recommandé d'autoriser l'accès uniquement depuis les réseaux internes VPC et de configurer des listes d'autorisation IP appropriées. Si l'endpoint public de Kibana est activé, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Contrôle d'accès réseau

Une instance MongoDB a un endpoint public activé et aucune liste d'autorisation d'adresses IP

Exposer des bases de données à l'Internet public pose des risques de sécurité. Elles deviennent visibles par les attaquants et peuvent subir des fuites ou des destructions de données en l'absence de contrôles d'accès appropriés. Il est recommandé d'autoriser l'accès uniquement depuis les réseaux internes VPC, de configurer des listes d'autorisation IP et d'utiliser des identifiants robustes. Si un endpoint public est activé, la configuration est non conforme.

Non pris en charge.

Non

Contrôle d'accès réseau

Un cluster PolarDB a un endpoint public configuré

Exposer des bases de données à l'Internet public pose des risques de sécurité. Elles deviennent visibles par les attaquants et peuvent subir des fuites ou des destructions de données en l'absence de contrôles d'accès appropriés. Il est recommandé d'autoriser l'accès uniquement depuis les réseaux internes VPC, de configurer des listes d'autorisation IP et d'utiliser des identifiants robustes. Si un endpoint public est activé, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Contrôle d'accès réseau

Une instance RDS a un endpoint public activé et aucune liste d'autorisation d'adresses IP

Exposer des bases de données à l'Internet public pose des risques de sécurité. Elles deviennent visibles par les attaquants et peuvent subir des fuites ou des destructions de données en l'absence de contrôles d'accès appropriés. Il est recommandé d'autoriser l'accès uniquement depuis les réseaux internes VPC, de configurer des listes d'autorisation IP et d'utiliser des identifiants robustes. Si un endpoint public est activé, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Contrôle d'accès réseau

Une instance Redis a un endpoint public configuré

Exposer des bases de données à l'Internet public pose des risques de sécurité. Elles deviennent visibles par les attaquants et peuvent subir des fuites ou des destructions de données en l'absence de contrôles d'accès appropriés. Il est recommandé d'autoriser l'accès uniquement depuis les réseaux internes VPC, de configurer des listes d'autorisation IP et d'utiliser des identifiants robustes. Si un endpoint public est activé, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Contrôle d'accès réseau

Une règle entrante de groupe de sécurité autorise l'accès depuis 0.0.0.0/0 à n'importe quel port

N'autorisez pas toutes les adresses IP (0.0.0.0/0) à accéder à n'importe quel port. Restreignez l'accès à des plages d'IP et des ports spécifiques. Si une règle entrante de groupe de sécurité autorise l'accès depuis 0.0.0.0/0 sans spécifier de ports, la configuration est non conforme.

Non pris en charge.

Non

Contrôle d'accès réseau

Une instance Tablestore a l'accès réseau public et classique activé

Tablestore crée un nom de domaine public, un nom de domaine VPC et un nom de domaine réseau classique pour chaque instance. Les noms de domaine public sont accessibles depuis Internet. Les noms de domaine réseau classique sont accessibles depuis les instances ECS de la même région. Il est recommandé d'autoriser l'accès uniquement depuis la console ou un VPC. Restreindre l'accès réseau public et classique améliore l'isolation réseau et la sécurité des données. Si le type de réseau est défini sur « Console ou VPC uniquement » ou « VPC uniquement », la configuration est conforme aux meilleures pratiques.

Non pris en charge.

Non

Contrôle d'accès réseau

Le serveur API d'un cluster ACK a un endpoint public activé (nouveau dans le modèle 3.0)

L'activation d'un endpoint public pour un cluster ACK augmente le risque d'attaques sur des resources telles que les pods, les services et les contrôleurs de réplicas. N'activez pas les endpoints publics. Si un endpoint public est activé, la configuration est non conforme.

Non pris en charge.

Non

Contrôle d'accès réseau

Le type de réseau d'un modèle de lancement ECS est défini sur réseau classique (nouveau dans le modèle 3.0)

Le réseau classique n'offre aucune isolation au niveau réseau entre les utilisateurs. Plusieurs locataires partagent le même pool d'IP, et les utilisateurs ne peuvent pas personnaliser les topologies réseau ou les adresses IP. Les vulnérabilités des applications en réseau classique peuvent les exposer à d'autres locataires. Virtual Private Cloud (VPC) offre une sécurité renforcée. Pour les organisations qui privilégient la sécurité des données, le VPC est le meilleur choix. Si un modèle de lancement ECS utilise le réseau classique, la configuration est non conforme.

Non pris en charge.

Non

Contrôle d'accès réseau

Le nœud maître d'un cluster EMR a un endpoint public activé (nouveau dans le modèle 3.0)

L'attribution d'une adresse IP publique à un nœud maître EMR augmente son exposition aux attaques. Des attaquants peuvent analyser, infiltrer ou effectuer d'autres actions malveillantes, menaçant ainsi l'ensemble du cluster. Si un endpoint public est activé, la configuration est non conforme.

Non pris en charge.

Non

Contrôle d'accès réseau

Une règle entrante du groupe de sécurité associé à un groupe de mise à l'échelle ESS autorise l'accès depuis 0.0.0.0/0 à n'importe quel port (nouveau dans le modèle 3.0)

Lorsque des activités de mise à l'échelle sont déclenchées, Auto Scaling crée des instances ECS selon la configuration de mise à l'échelle. Si la règle entrante du groupe de sécurité associé autorise toutes les adresses IP (0.0.0.0/0) sur n'importe quel port, les nouvelles instances sont exposées à des risques de sécurité. Si une telle règle existe, la configuration est non conforme.

Non pris en charge.

Non

Contrôle d'accès réseau

Un projet MaxCompute n'a pas de liste d'autorisation d'adresses IP (nouveau dans le modèle 3.0)

Avec une liste d'autorisation d'adresses IP, seuls les appareils listés peuvent accéder au projet. Sans liste d'autorisation, tout appareil utilisant un endpoint public peut accéder au projet, ce qui pose des risques d'exposition. Si le projet autorise l'accès au réseau externe sans liste d'autorisation d'adresses IP, la configuration est non conforme.

Non pris en charge.

Non

Contrôle d'accès réseau

Un groupe de sécurité expose des ports à haut risque (22, 3389, etc.) à l'Internet public

N'autorisez pas l'accès depuis l'Internet public à des ports à haut risque tels que SSH (22) et RDP (3389) pour prévenir les attaques et les accès non autorisés. Si de tels ports sont exposés, la configuration est non conforme.

Non pris en charge.

Non

Protection réseau

Une instance NAT Gateway n'est pas entièrement protégée par le NAT Border Firewall

Pour réduire l'exposition du réseau privé à l'Internet public, toutes les instances NAT Gateway doivent être protégées par le NAT Border Firewall de Cloud Firewall. Si Cloud Firewall est utilisé mais que certaines passerelles NAT ne sont pas protégées, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Non pris en charge.

Non

Protection réseau

Le trafic inter-VPC n'est pas entièrement protégé par le VPC Border Firewall

Tout le trafic inter-VPC doit transiter par le VPC Border Firewall de Cloud Firewall pour réduire les risques liés au trafic interne. Si Cloud Firewall est utilisé mais que certains trafics inter-VPC ne sont pas protégés, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Non pris en charge.

Non

Protection réseau

La défense de base n'est pas activée dans le système de prévention des intrusions (IPS) de Cloud Firewall

Activez la défense de base dans le système de prévention des intrusions (IPS) de Cloud Firewall. Elle fournit une protection fondamentale, notamment le blocage des attaques par force brute, des exploits d'exécution de commandes et des communications C&C. Si Cloud Firewall est utilisé mais que la défense de base est désactivée, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Non pris en charge.

Non

Protection réseau

Le renseignement sur les menaces n'est pas activé dans le système de prévention des intrusions (IPS) de Cloud Firewall

Activez le renseignement sur les menaces dans l'IPS de Cloud Firewall pour analyser les menaces et bloquer les activités malveillantes. Si Cloud Firewall est utilisé mais que le renseignement sur les menaces est désactivé, la configuration est non conforme.

Non pris en charge.

Non

Protection réseau

Le mode Blocage n'est pas activé dans le système de prévention des intrusions (IPS) de Cloud Firewall

Configurez l'IPS de Cloud Firewall en mode Blocage pour intercepter le trafic malveillant et stopper les intrusions. Si Cloud Firewall est utilisé mais que le mode Blocage est désactivé, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Cette correction active le mode Blocage pour le moteur de menaces. La sévérité est définie par défaut sur Moyenne.

Non

Protection réseau

Le correctif virtuel n'est pas activé dans le système de prévention des intrusions (IPS) de Cloud Firewall

Activez le correctif virtuel dans l'IPS de Cloud Firewall. Il fournit une protection en temps réel contre les vulnérabilités critiques et urgentes au niveau réseau, empêchant leur exploitation sans interrompre les services. Si Cloud Firewall est utilisé mais que le correctif virtuel est désactivé, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Non pris en charge.

Non

Protection réseau

Cloud Firewall dispose d'autorisations disponibles insuffisantes

Cette vérification confirme que le nombre d'autorisations de Cloud Firewall est suffisant. Si Cloud Firewall est utilisé mais que le nombre d'actifs IP public non protégés dépasse le nombre d'autorisations disponibles, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Non pris en charge.

Non

Protection réseau

Aucune politique de refus par défaut n'est configurée dans Cloud Firewall

Pour la sécurité réseau, configurez une politique de refus par défaut (une politique IPv4 avec source et destination définies sur 0.0.0.0/0 et action définie sur Refuser). Cela bloque tout le trafic sauf le trafic de confiance explicitement autorisé. Si Cloud Firewall est utilisé mais qu'aucune politique de refus par défaut n'est configurée, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Non pris en charge.

Non

Protection réseau

Cloud Firewall ne protège pas tous les actifs IP public

Cette vérification confirme que tous les actifs IP public sont protégés par Cloud Firewall. Si Cloud Firewall est utilisé mais que certains actifs IP public ne bénéficient pas de la protection Internet Border Firewall, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Non pris en charge.

Non

Protection réseau

Aucune politique de liste de contrôle d'accès (ACL) n'est configurée dans Cloud Firewall

Après l'activation du pare-feu, si aucune politique ACL n'est configurée, Cloud Firewall autorise par défaut tout le trafic. Configurez des politiques ACL pour contrôler les accès non autorisés. Si Cloud Firewall est utilisé mais qu'aucune politique ACL n'existe, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Non pris en charge.

Non

Protection réseau

La bande passante de protection de Cloud Firewall est insuffisante

Cette vérification confirme que la bande passante de protection de Cloud Firewall est suffisante. Si Cloud Firewall est utilisé mais que la bande passante de pointe des 30 derniers jours dépasse la bande passante achetée, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Non pris en charge.

Non

Protection réseau

Cloud Firewall n'est pas utilisé pour protéger le trafic réseau

Cloud Firewall est un pare-feu SaaS qui fournit une isolation de sécurité unifiée pour les frontières Internet, VPC et hôtes. Il constitue la première ligne de défense pour les charges de travail cloud. Si Cloud Firewall n'est pas utilisé, la configuration n'est pas conforme aux meilleures pratiques de sécurité réseau.

Non pris en charge.

Non

Contrôle d'accès aux données

Un bucket OSS a des permissions d'écriture publique activées

OSS prend en charge l'accès public via des politiques de bucket et des ACL. L'écriture publique signifie que n'importe qui peut modifier ou télécharger des objets sans permissions ni authentification. Cela entraîne des risques de fuites de données et d'accès malveillants pouvant générer des coûts élevés. Il est recommandé de désactiver les permissions d'écriture publique. Accédez aux données OSS uniquement via des URL signées ou des API. Si la politique de bucket ou l'ACL contient une sémantique d'écriture publique, le bucket est à risque et n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Contrôle d'accès aux données

Un bucket OSS comporte des règles d'accès pour comptes anonymes

L'application du principe du moindre privilège réduit les risques de sécurité et limite l'impact des erreurs ou des comportements malveillants. Si une politique de bucket OSS autorise l'accès anonyme, des attaquants peuvent exfiltrer des données. Si des comptes externes sont compromis, vos données peuvent être modifiées ou supprimées, menaçant leur intégrité, leur confidentialité et la continuité d'activité. Il est recommandé de bloquer l'accès anonyme via des politiques. Si la politique de bucket accorde l'accès à * (tous les comptes) avec un effet Allow, elle n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Contrôle d'accès aux données

Un bucket OSS comporte des règles d'accès pour des comptes extérieurs à l'organisation

Assurez-vous que les buckets OSS sont accessibles uniquement aux comptes internes pour prévenir les fuites de données. Si la politique d'autorisation du bucket autorise des comptes externes, la configuration est non conforme.

Non pris en charge.

Non

Contrôle d'accès aux données

Un bucket OSS a des permissions de lecture publique activées

Empêchez l'accès en lecture publique au contenu des buckets OSS pour garantir la confidentialité et la sécurité des données. Si les permissions de lecture publique sont activées, la configuration est non conforme.

Non pris en charge.

Non

Protection des données en transit

Un certificat serveur SLB risque d'expirer

Assurez-vous que les certificats serveur SLB n'expirent pas dans les 15 jours pour éviter les échecs de chiffrement. Si la validité restante est de 15 jours ou moins, la configuration est non conforme.

Non pris en charge.

Non

Protection des données en transit

Une API dans API Gateway avec un endpoint public n'a pas HTTPS configuré

L'utilisation exclusive de HTTP pour les API publiques pose des risques de sécurité des données. HTTP transmet les données en texte clair, permettant aux attaquants de voir des informations sensibles telles que des identifiants et des données privées. Il est recommandé d'utiliser HTTPS pour les API publiques et de forcer la redirection HTTP vers HTTPS pour garantir une transmission chiffrée. Si le domaine API Gateway n'a pas HTTPS configuré, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Protection des données en transit

Un certificat SSL CDN approche de l'expiration (nouveau dans le modèle 3.0)

Assurez-vous que les certificats SSL/TLS liés aux domaines restent valides pour éviter les risques de sécurité et les interruptions de service. Si le certificat CDN expire dans moins de 15 jours, la configuration est non conforme.

Non pris en charge.

Non

Protection des données en transit

La redirection forcée HTTP vers HTTPS n'est pas configurée pour les domaines CDN

L'utilisation exclusive de HTTP pour les domaines CDN pose des risques de sécurité des données. HTTP transmet les données en texte clair, permettant aux attaquants de voir des informations sensibles telles que des identifiants et des données privées. Il est recommandé d'utiliser HTTPS pour les domaines CDN et de forcer la redirection HTTP vers HTTPS pour garantir une transmission chiffrée. Si le type de redirection forcée du domaine CDN n'est pas défini sur HTTP→HTTPS, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Protection des données en transit

HTTPS n'est pas configuré pour les domaines CDN

L'utilisation exclusive de HTTP pour les domaines CDN pose des risques de sécurité des données. HTTP transmet les données en texte clair, permettant aux attaquants de voir des informations sensibles telles que des identifiants et des données privées. Il est recommandé d'utiliser HTTPS pour les domaines CDN et de forcer la redirection HTTP vers HTTPS pour garantir une transmission chiffrée. Si l'accélération sécurisée HTTPS n'est pas activée pour le domaine CDN, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Protection des données en transit

Une instance Elasticsearch n'utilise pas HTTPS

L'utilisation exclusive de HTTP pour Elasticsearch pose des risques de sécurité des données. HTTP transmet les données en texte clair, permettant aux attaquants de voir des informations sensibles. Il est recommandé d'utiliser HTTPS pour accéder à Elasticsearch depuis des applications ou des clients afin de garantir une transmission chiffrée. Si le paramètre réseau du cluster active HTTPS, la configuration est conforme aux meilleures pratiques.

Non pris en charge.

Non

Protection des données en transit

Les écouteurs HTTPS ne sont pas activés sur une instance SLB

Assurez-vous que Server Load Balancer (SLB) a des écouteurs HTTPS activés pour chiffrer les données en transit via TLS. Si les écouteurs HTTPS ne sont pas activés, la configuration est non conforme.

Non pris en charge.

Non

Protection des données en transit

Un certificat dans Certificate Management Service risque d'expirer

Après l'expiration d'un certificat SSL, les clients ne peuvent pas vérifier l'identité du serveur, ce qui provoque des échecs d'accès ou des avertissements. Un renouvellement tardif peut réduire la disponibilité du service, éroder la confiance des clients ou causer des fuites de données. Prévoyez un délai suffisant pour le renouvellement afin d'éviter les interruptions. Si un certificat dans Certificate Management Service expire dans 15 jours ou moins, la configuration n'est pas conforme aux meilleures pratiques.

Non pris en charge.

Non

Protection des données en transit

TLS v1.2 n'est pas activé sur un site ESA

Cette vérification confirme que les sites ont TLS v1.2 activé pour améliorer la sécurité. S'il n'est pas activé, la configuration n'est pas conforme aux meilleures pratiques de sécurité des données en transit.

Non pris en charge.

Non

Protection des données en transit

HTTP Strict Transport Security (HSTS) n'est pas activé sur un site ESA

Cette vérification confirme que les sites ont HSTS activé pour réduire les risques de détournement lors de la première visite. S'il n'est pas activé, la configuration n'est pas conforme aux meilleures pratiques de sécurité des données en transit.

Non pris en charge.

Non

Protection des données en transit

HTTPS forcé n'est pas activé sur un site ESA

Cette vérification confirme que les sites ont HTTPS forcé activé pour rediriger les requêtes HTTP des clients vers les nœuds de périphérie ESA vers HTTPS. S'il n'est pas activé, la configuration n'est pas conforme aux meilleures pratiques de sécurité des données en transit.

Non pris en charge.

Non

Masquage des données

L'identification des données sensibles n'est pas activée dans Data Security Center (nouveau dans le modèle 3.0)

Les données sensibles incluent les données clients, les documents techniques et les informations personnelles. Data Security Center analyse les bases de données à la recherche de données sensibles à l'aide de règles prédéfinies et de comptages d'occurrences. Les bases de données prises en charge incluent MaxCompute, OSS, les services ApsaraDB (RDS, PolarDB-X, PolarDB, OceanBase et Tablestore) et les bases de données auto-gérées. Si l'identification des données sensibles est désactivée, la configuration est non conforme.

Non pris en charge.

Non

Protection des données au repos

Le chiffrement transparent des données (TDE) n'est pas activé sur un cluster PolarDB (nouveau dans le modèle 3.0)

TDE effectue un chiffrement et un déchiffrement E/S en temps réel sur les fichiers de données. Les données sont chiffrées avant d'être écrites sur disque et déchiffrées lors de leur chargement en mémoire. Si TDE est désactivé pour PolarDB, des fuites de données, des accès non autorisés ou des altérations peuvent survenir. Si TDE est désactivé, la configuration est non conforme.

Non pris en charge.

Non

Protection des données au repos

Le chiffrement transparent des données (TDE) n'est pas activé sur une instance RDS (nouveau dans le modèle 3.0)

Utilisez TDE pour le chiffrement et le déchiffrement E/S en temps réel dans des scénarios de conformité de sécurité ou de chiffrement des données au repos. TDE chiffre les données au niveau de la base de données, empêchant les attaquants de lire directement les données sensibles depuis le stockage. Si TDE est désactivé pour RDS, la configuration est non conforme.

Non pris en charge.

Non

Réponse et récupération après incident de sécurité

Security Center présente des alertes en attente

Les alertes de sécurité indiquent des menaces détectées par Security Center sur vos serveurs ou produits cloud. Les types d'alertes incluent Web Tamper Protection, les processus anormaux, les shells web, les connexions anormales et les processus malveillants. Le traitement des alertes améliore votre posture de sécurité. Si des alertes en attente existent, la configuration est non conforme.

Non pris en charge.

Non

Réponse et récupération après incident de sécurité

Security Center n'est pas utilisé pour la protection de sécurité (nouveau dans le modèle 3.0)

Les actifs cloud font face à des menaces telles que les virus, les cyberattaques, les ransomwares et les exploits de vulnérabilités. Security Center fournit la gestion des actifs, des vérifications de configuration et une défense proactive. Souscrivez aux services de sécurité appropriés pour bâtir un système de défense. Si l'édition de Security Center est Basic ou inférieure, la configuration est non conforme.

Non pris en charge.

Non

Catégorie

Élément de contrôle

Description de l'élément de contrôle

Description de la correction rapide

Prise en charge de l'aide à la décision

Types d'instance

Le cluster ACK utilise l'édition Basic du cluster géré

Les clusters gérés ACK se déclinent en édition Basic et édition Pro. L'édition Pro améliore davantage la fiabilité, la sécurité et l'ordonnancement du cluster par rapport à l'édition Basic, ce qui la rend plus adaptée à l'exécution de services à grande échelle dans un environnement de production. Un compte est considéré comme non conforme s'il n'utilise pas l'édition Pro du type de cluster géré.

La correction rapide n'est pas prise en charge.

Non

Types d'instance

L'instance ECS utilise un type d'instance partagé ou abandonné

L'utilisation d'un type d'instance partagé ou abandonné pour une instance ECS ne garantit pas des performances de calcul stables. L'emploi d'une famille d'instances ECS partagée ou abandonnée est considéré comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Types d'instance

L'instance Elasticsearch utilise un type d'instance de développement et de test

Une instance Elasticsearch dotée d'un cœur et de 2 Go de mémoire convient uniquement aux scénarios de test, et non aux environnements de production. L'utilisation d'une instance Elasticsearch avec 1 cœur et 2 Go de mémoire est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Types d'instance

L'instance MongoDB utilise un type d'instance à nœud unique

Lorsque MongoDB adopte une architecture à nœud unique, le temps de reprise après incident est long et aucune garantie SLA n'est offerte. L'utilisation d'une instance MongoDB qui n'est pas multizone est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Types d'instance

L'instance RDS utilise un type d'instance de la série Basic

Une instance de la série Basic RDS ne possède qu'un seul nœud de base de données et aucun nœud secondaire servant de sauvegarde à chaud. Par conséquent, en cas de panne inattendue du nœud ou lors d'opérations telles que le redémarrage de l'instance, la modification de la configuration ou la mise à niveau de la version, elle reste indisponible pendant une longue période. De plus, les types d'instance partagés et polyvalents de la famille d'instances RDS partagent leurs ressources avec d'autres instances sur la même machine physique ; ils conviennent donc uniquement aux scénarios d'application exigeant une faible stabilité. Si votre activité requiert une haute disponibilité de la base de données, il est recommandé d'utiliser la série Haute disponibilité/Cluster pour la série de produits et le type Dédié pour la famille d'instances. Une instance RDS est jugée non conforme si la série de produits RDS n'utilise pas la série Haute disponibilité/Cluster, ou si la famille d'instances RDS n'utilise pas le type Dédié.

La correction rapide n'est pas prise en charge.

Non

Types d'instance

L'instance Redis utilise un type d'instance de l'édition open source

Redis Enterprise Edition offre des performances supérieures, davantage de structures de données et des méthodes de stockage plus flexibles. Ne pas utiliser Redis Enterprise Edition est considéré comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Types d'instance

L'instance ApsaraMQ for RocketMQ utilise un type d'instance Standard Edition

L'édition Standard d'ApsaraMQ for RocketMQ repose sur une instance partagée et n'est pas recommandée pour un environnement de production. L'utilisation d'une édition partagée d'une instance RocketMQ est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Version stable

Le cluster ACK utilise une version Kubernetes expirée

La communauté Kubernetes publie une version mineure environ tous les quatre mois. Nous vous recommandons d'utiliser une version encore maintenue. Les clusters exécutant une version expirée présentent des risques de sécurité et de stabilité. Une fois la version du cluster expirée, vous ne bénéficiez plus des fonctionnalités ni des correctifs pris en charge par la nouvelle version Kubernetes, vous ne recevez plus de support technique efficace et opportun, et vous ne pouvez plus corriger les vulnérabilités de sécurité. L'utilisation d'une version de cluster ACK toujours maintenue est conforme.

La correction rapide n'est pas prise en charge.

Non

Version stable

L'instance ECS utilise une version de système d'exploitation expirée

L'utilisation d'une version de système d'exploitation qui n'est plus prise en charge pour une instance ECS est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Version stable

L'instance Elasticsearch utilise une version non recommandée

Une instance Elasticsearch est considérée comme non conforme si la version utilisée ne figure pas dans la plage de versions officiellement recommandées.

La correction rapide n'est pas prise en charge.

Non

Versions stables

La version du moteur MSE est trop ancienne

L'utilisation de la dernière version du moteur MSE est essentielle pour garantir la continuité de service de MSE. Si la version du moteur est trop ancienne, cela peut entraîner divers problèmes : défauts de code empêchant la récupération par le GC, débordements mémoire provoquant une croissance continue de la mémoire, lenteurs au démarrage ou encore défauts de sérialisation JSON. Un compte est considéré comme non conforme si la version du moteur MSE-ZooKeeper ou MSE-ANS, ou la version du client MSE-ANS, est trop ancienne.

La correction rapide n'est pas prise en charge.

Non

Versions stables

La version de la passerelle MSE-Ingress est trop ancienne

L'utilisation de la dernière version d'Ingress est essentielle pour garantir la continuité de service de la passerelle. Une version trop ancienne peut engendrer des risques de sécurité ou de stabilité, et conduire à une liste d'instances inexacte pour l'abonnement aux services Nacos. Un compte est considéré comme non conforme si la version MSE-Ingress est trop ancienne.

La correction rapide n'est pas prise en charge.

Non

Versions stables

La version majeure de la base de données MySQL de l'instance RDS est trop ancienne (Nouveau dans le modèle 3.0)

L'utilisation d'une version MySQL dont le cycle de vie est terminé ou sur le point de l'être expose le système à des risques de sécurité, des goulots d'étranglement des performances, des problèmes de compatibilité et à l'absence de support technique. La mise à niveau opportune vers une version MySQL prise en charge permet de bénéficier des derniers correctifs de sécurité, des améliorations de performances et des nouvelles fonctionnalités, réduisant ainsi les risques d'exploitation et de maintenance (O&M) tout en améliorant la fiabilité globale du système. Une instance RDS est considérée comme non conforme si elle utilise la version 5.5 ou 5.6.

La correction rapide n'est pas prise en charge.

Non

Version stable

La fonction Function Compute (FC) 2.0 utilise un runtime obsolète (Nouveau dans le modèle 3.0)

Au fil des itérations des versions de runtime, Function Compute cesse de maintenir certains runtimes et ne fournit plus de support technique ni de mises à jour de sécurité pour ceux-ci. Nous vous recommandons de migrer vos fonctions vers le dernier runtime pris en charge afin de continuer à bénéficier du support technique et des mises à jour de sécurité. Une fonction FC 2.0 est considérée comme non conforme si elle utilise l'un des runtimes suivants : nodejs12, nodejs10, nodejs8, dotnetcore2.1, python2.7, nodejs6 ou nodejs4.4.

La correction rapide n'est pas prise en charge.

Non

Versions stables

L'inspection du cluster ACK révèle que la version du composant Kubelet sur un nœud est en retard par rapport au plan de contrôle (Nouveau dans le modèle 3.0)

Si la version du composant Kubelet sur un nœud du cluster ACK est en retard par rapport au plan de contrôle, cela peut provoquer des problèmes de compatibilité. Le plan de contrôle, tel que l'API Server, pourrait ne plus communiquer avec une version ancienne de Kubelet en raison de nouvelles fonctionnalités ou de mises à niveau de protocole. Cela peut entraîner un statut de nœud anormal, des échecs d'ordonnancement des Pods ou le marquage des nœuds comme indisponibles. En outre, les anciennes versions de Kubelet peuvent contenir des vulnérabilités de sécurité non corrigées, ce qui accroît le risque d'attaques sur les nœuds et entrave la capacité de mise à niveau globale du cluster. Pour rétablir la stabilité des communications et éliminer les risques de sécurité, vous devez mettre à niveau Kubelet vers une version compatible. Un nœud dont la version Kubelet est en retard par rapport au plan de contrôle est considéré comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Version stable

La base de données du cluster PolarDB n'utilise pas une version mineure stable

Une base de données PolarDB est considérée comme non conforme si le statut de sa version mineure n'est ni Stable ni Bêta.

Cette correction active la mise à niveau automatique de la version mineure pour l'instance spécifiée. Lorsque votre version mineure du moteur est inférieure à la dernière version mineure disponible, le système émet périodiquement des tâches O&M actives pour effectuer la mise à niveau. Cette opération automatique s'exécute durant la fenêtre de maintenance que vous avez définie. Pendant le processus de mise à niveau, le proxy de base de données (PolarProxy) ou le moteur noyau (DB) redémarre, ce qui peut provoquer une interruption momentanée de connexion. Effectuez cette opération pendant les heures creuses et assurez-vous que votre application dispose d'un mécanisme de reconnexion automatique.

Non

Version stable

La mise à niveau automatique de la version mineure du moteur n'est pas activée pour l'instance RDS (Nouveau dans le modèle 3.0)

ApsaraDB RDS prend en charge la mise à niveau automatique ou manuelle de la version mineure du moteur. Lorsque la version mineure du moteur est inférieure à la dernière version disponible, le système émet périodiquement des tâches O&M actives pour effectuer la mise à niveau. L'instance obtient ainsi la dernière version, incluant des améliorations de performances, la prise en charge de nouvelles fonctionnalités et des correctifs de sécurité, garantissant l'optimisation continue et la sécurité du service de base de données. Une instance RDS est considérée comme non conforme si la mise à niveau automatique de la version mineure du moteur n'est pas activée.

Cette correction active automatiquement la mise à niveau automatique de la version mineure du moteur pour l'instance RDS sélectionnée. Lorsque la version mineure du moteur de l'instance RDS est inférieure à la dernière version disponible, le système émet périodiquement des tâches O&M actives pour effectuer la mise à niveau. Cette opération automatique s'exécute durant la fenêtre de maintenance que vous avez définie. Les informations relatives aux tâches de mise à niveau émises par le système sont notifiées via des canaux tels que les SMS et les e-mails configurés dans le Centre des messages.

Non

Version stable

L'instance Redis n'a pas été mise à niveau vers la dernière version mineure

Une instance Redis est considérée comme non conforme si elle n'a pas été mise à niveau vers la dernière version mineure.

Cette correction active la mise à niveau automatique de la version mineure pour l'instance sélectionnée. Une fois activée, le système vérifie périodiquement l'état des publications de versions. Si une nouvelle version est détectée, elle est automatiquement installée dans un délai de 60 jours. Lors de la mise à niveau de la version de la base de données, l'instance met d'abord à niveau l'instance secondaire (Réplica) ou prépare une nouvelle instance. À l'heure d'exécution spécifiée, un basculement primaire/secondaire ou un basculement d'instance est effectué pour finaliser l'opération. Durant la phase de basculement, l'instance passe en lecture seule pendant 60 secondes maximum en attendant la synchronisation complète des données, et une brève interruption de connexion de quelques secondes se produit. Assurez-vous que votre application dispose d'un mécanisme de reconnexion.

Non

Risques d'expiration

L'instance AnalyticDB for MySQL Data Warehouse Edition risque d'expirer

Une instance AnalyticDB for MySQL Data Warehouse Edition est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure du contrôle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance ADB par abonnement sélectionnée.

Non

Risques d'expiration

L'instance Anti-DDoS risque d'expirer

Une instance DDoS est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure actuelle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance DDoSCOO par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

L'instance ECS risque d'expirer

Une instance ECS par abonnement est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure du contrôle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance ECS par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

L'instance EIP risque d'expirer

Une instance EIP par abonnement est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure du contrôle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance EIP par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

L'instance KMS risque d'expirer (Nouveau dans le modèle 3.0)

Assurez-vous de renouveler à temps vos instances KMS par abonnement afin d'éviter toute interruption d'activité due à leur expiration. Une instance KMS par abonnement est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure du contrôle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance KMS par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

L'instance MongoDB risque d'expirer

Une instance MongoDB par abonnement est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure du contrôle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance MongoDB par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

Le cluster PolarDB risque d'expirer

Une instance PolarDB par abonnement est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure du contrôle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance PolarDB par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

L'instance PolarDB-X risque d'expirer

Une instance PolarDB-X 1.0 ou PolarDB-X 2.0 est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure actuelle et que le renouvellement automatique n'est pas activé.

La correction rapide n'est pas prise en charge.

Non

Risques d'expiration

L'instance RDS risque d'expirer

Une instance RDS par abonnement est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure du contrôle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance RDS par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

L'instance Redis risque d'expirer

Une instance Redis par abonnement est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure du contrôle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance Redis par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

L'instance SLB risque d'expirer

Une instance SLB par abonnement est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure du contrôle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance SLB par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

VPN Gateway risque d'expirer (Nouveau dans le modèle 3.0)

Assurez-vous de renouveler à temps vos instances VPN Gateway par abonnement afin d'éviter toute interruption d'activité due à leur expiration. Une instance VPN Gateway par abonnement est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure du contrôle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance VPN par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

Le plan de bande passante CEN risque d'expirer

Un plan de bande passante Cloud Enterprise Network est considéré comme non conforme s'il doit expirer dans moins de 7 jours à compter de l'heure actuelle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance CEN par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

L'instance de bande passante partagée risque d'expirer

Une instance de bande passante partagée est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure actuelle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour votre resource CBWP sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Risques d'expiration

L'instance Bastionhost risque d'expirer

Une instance Bastionhost est considérée comme non conforme si elle doit expirer dans moins de 7 jours à compter de l'heure du contrôle et que le renouvellement automatique n'est pas activé.

Cette correction active le renouvellement automatique pour la resource d'instance Bastionhost par abonnement sélectionnée. Une fois activé, le renouvellement automatique prend effet le lendemain. Activez le renouvellement automatique au moins 2 jours avant l'expiration de l'instance par abonnement. Si votre instance doit expirer le lendemain, nous vous recommandons d'accéder à la console du produit pour effectuer un renouvellement manuel. Le cycle de renouvellement automatique dépend de la durée de renouvellement définie. Par exemple, si vous sélectionnez une durée de 1 mois, l'instance est automatiquement renouvelée pour 1 mois avant chaque expiration. Assurez-vous que le solde de votre compte, vos bons de réduction ou vos autres moyens de paiement suffisent à couvrir le montant du renouvellement.

Non

Protection contre la suppression

La protection contre la suppression n'est pas activée pour le cluster ACK

Un cluster ACK est considéré comme non conforme si la protection contre la suppression n'est pas activée.

Cette correction active la protection contre la suppression pour la resource sélectionnée. La resource ne peut être libérée ni via la console, ni via l'API, ni via la ligne de commande. Pour libérer l'instance, accédez d'abord à la page des détails de l'instance pour désactiver l'option de protection contre la suppression.

Non

Protection contre la suppression

La protection contre la suppression n'est pas activée pour l'instance ALB

Une instance ALB est considérée comme non conforme si la protection contre la suppression n'est pas activée.

Cette correction active la protection contre la suppression pour la resource sélectionnée. La resource ne peut être libérée ni via la console, ni via l'API, ni via la ligne de commande. Pour libérer l'instance, accédez d'abord à la page des détails de l'instance pour désactiver l'option de protection contre la suppression.

Non

Protection contre la suppression

La protection contre la suppression n'est pas activée pour l'instance EIP

Une instance EIP est considérée comme non conforme si la protection contre la suppression n'est pas activée.

Cette correction active la protection contre la suppression pour la resource sélectionnée. La resource ne peut être libérée ni via la console, ni via l'API, ni via la ligne de commande. Pour libérer l'instance, accédez d'abord à la page des détails de l'instance pour désactiver l'option de protection contre la suppression.

Non

Protection contre la suppression

La protection contre la libération n'est pas activée pour l'instance MongoDB

Une instance MongoDB est considérée comme non conforme si la protection contre la libération n'est pas activée.

Cette correction active la protection contre la suppression pour la resource sélectionnée. La resource ne peut être libérée ni via la console, ni via l'API, ni via la ligne de commande. Pour libérer l'instance, accédez d'abord à la page des détails de l'instance pour désactiver l'option de protection contre la suppression.

Non

Protection contre la suppression

Le verrouillage du cluster n'est pas activé pour le cluster PolarDB

Une instance PolarDB est considérée comme non conforme si le verrouillage du cluster n'est pas activé.

Cette correction active la protection contre la suppression pour la resource sélectionnée. La resource ne peut être libérée ni via la console, ni via l'API, ni via la ligne de commande. Pour libérer l'instance, accédez d'abord à la page des détails de l'instance pour désactiver l'option de protection contre la suppression.

Non

Protection contre la suppression

La protection contre la libération n'est pas activée pour l'instance RDS

Une instance RDS est considérée comme non conforme si la protection contre la libération n'est pas activée.

Cette correction active la protection contre la suppression pour la resource sélectionnée. La resource ne peut être libérée ni via la console, ni via l'API, ni via la ligne de commande. Pour libérer l'instance, accédez d'abord à la page des détails de l'instance pour désactiver l'option de protection contre la suppression.

Non

Protection contre la suppression

La protection contre la suppression n'est pas activée pour l'instance SLB

Une instance SLB est considérée comme non conforme si la protection contre la suppression n'est pas activée.

Cette correction active la protection contre la suppression pour la resource sélectionnée. La resource ne peut être libérée ni via la console, ni via l'API, ni via la ligne de commande. Pour libérer l'instance, accédez d'abord à la page des détails de l'instance pour désactiver l'option de protection contre la suppression.

Non

Inspection des risques

L'inspection du cluster ACK révèle que l'instance CLB liée à l'API Server n'existe pas (Nouveau dans le modèle 3.0)

Si l'API Server d'un cluster ACK n'est lié à aucune instance Classic Load Balancer (CLB), le service API ne dispose d'aucun point d'entrée pour le trafic. Les clients externes tels que kubectl ne peuvent pas accéder à l'API Server via l'équilibrage de charge, ce qui interrompt totalement la gestion du cluster. Les composants du cluster comme kubelet et les contrôleurs peuvent provoquer des statuts de nœud anormaux, des échecs d'ordonnancement des Pods et une indisponibilité des services en raison de l'impossibilité d'établir une communication stable. Parallèlement, le nœud API Server expose directement son adresse IP, perdant ainsi les capacités de distribution du trafic et de basculement, ce qui crée un risque de point de défaillance unique et accroît la menace d'accès non autorisés ou d'attaques DDoS. Une instance CLB doit être créée et liée immédiatement pour rétablir la haute disponibilité et sécuriser l'accès. Un cluster ACK est considéré comme non conforme si son API Server n'est lié à aucune instance CLB.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que l'instance CLB liée à l'API Server est dans un état anormal (Nouveau dans le modèle 3.0)

Si l'instance CLB liée à l'API Server d'un cluster ACK est dans un état anormal, le transfert du trafic du service API échoue. Les clients tels que kubectl ne peuvent pas établir de connexion stable, ce qui bloque totalement la gestion du cluster. Les composants internes comme kubelet et les contrôleurs provoquent des statuts de nœud anormaux une stagnation de l'ordonnancement des Pods et une indisponibilité des services en raison de l'interruption des communications. Parallèlement, l'échec du contrôle de santé CLB peut concentrer le trafic sur des nœuds défectueux, aggravant les risques de point de défaillance unique. Si cet état anormal s'accompagne d'erreurs de configuration de sécurité (absence de chiffrement ou ports exposés), cela peut conduire à des accès non autorisés ou à des attaques de l'homme du milieu. L'état de santé du CLB doit être réparé immédiatement et la politique de sécurité vérifiée pour éviter la paralysie du cluster et les fuites de données. Un cluster ACK est considéré comme non conforme si l'instance CLB liée à son API Server est dans un état anormal.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que la configuration de l'écouteur de port CLB liée à l'API Server est anormale (Nouveau dans le modèle 3.0)

Si la configuration de l'écouteur de port CLB liée à l'API Server d'un cluster ACK est anormale, l'accès au service API est interrompu. Les clients tels que kubectl ne peuvent pas se connecter au cluster, et les opérations O&M échouent totalement. Parallèlement, les composants internes comme kubelet et les contrôleurs provoquent des statuts de nœud anormaux, des échecs d'ordonnancement des Pods et une indisponibilité des services en raison de l'impossibilité de communiquer avec l'API Server. Si le protocole de l'écouteur est incorrect ou si les restrictions de groupe de sécurité sont absentes, cela peut entraîner des risques d'accès non autorisés ou de détournement de trafic. La configuration du port d'écoute doit être réparée immédiatement, et le type de protocole ainsi que la politique de sécurité doivent être vérifiés pour éviter la paralysie du cluster et les fuites de données. Un cluster ACK est considéré comme non conforme si la configuration de l'écouteur de port CLB liée à son API Server est anormale.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que le nombre de serveurs backend pour le service CoreDNS est égal à 0 (Nouveau dans le modèle 3.0)

Si le nombre de serveurs backend pour CoreDNS dans un cluster ACK est égal à 0, la découverte de services échoue totalement. La communication interservices au sein du cluster, telle que les appels de microservices et l'accès aux bases de données, est interrompue, et les applications ne peuvent plus résoudre les adresses via les noms de service, ce qui affecte directement la disponibilité de l'activité. Cela engendre également des risques pour la stabilité du cluster. Un cluster ACK est considéré comme non conforme si le nombre de serveurs backend pour son service CoreDNS est égal à 0.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

Le taux d'erreurs 5xx de l'ALB est trop élevé (Nouveau dans le modèle 3.0)

Si le taux d'erreurs 5xx d'une instance ALB dépasse continuellement un seuil spécifié pendant une certaine période, cela indique que le service backend rencontre fréquemment des erreurs internes. Cela peut être causé par des exceptions d'application, des ressources insuffisantes, des erreurs de configuration ou des défaillances de services dépendants. Cela conduit directement à une dégradation de l'expérience utilisateur, à une augmentation du risque d'interruption d'activité et affecte la stabilité et la disponibilité du système. Une instance ALB est considérée comme non conforme si son taux d'erreurs 5xx est supérieur ou égal à 80 % pendant au moins 8 heures dans une plage de temps donnée par le passé.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

Le taux d'échec du handshake TLS de l'ALB est trop élevé (Nouveau dans le modèle 3.0)

Un taux élevé d'échecs de handshake TLS sur l'ALB peut indiquer des problèmes de communication chiffrée entre le client et le serveur, tels que des erreurs de configuration de certificat, des versions de protocole incompatibles, des suites de clés inadaptées ou l'utilisation par le client d'un algorithme de chiffrement non pris en charge. Cela provoque non seulement des échecs d'accès utilisateur et affecte la disponibilité de l'activité, mais peut aussi exposer des vulnérabilités de sécurité et augmenter le risque d'attaques de l'homme du milieu. Une instance ALB est considérée comme non conforme si son taux d'échec de handshake TLS est supérieur ou égal à 80 % pendant au moins 8 heures dans une plage de temps donnée par le passé.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

Le taux d'échec de connexion de l'ALB est trop élevé (Nouveau dans le modèle 3.0)

Un taux élevé d'échecs de connexion pour un Application Load Balancer (ALB) peut indiquer que le service backend est anormal, que le réseau est instable ou que la configuration est incorrecte. Cela peut entraîner des échecs d'accès utilisateur, des interruptions d'activité et une dégradation de l'expérience utilisateur. En inspectant la métrique du taux d'échec de connexion de l'ALB, vous pouvez découvrir et localiser rapidement la cause racine du problème, ce qui améliore la disponibilité et la stabilité du système, optimise l'efficacité de l'ordonnancement du trafic et garantit la continuité de l'activité ainsi que la qualité du service. Cela offre aux clients des capacités de diffusion d'applications cloud plus fiables. Une instance ALB est considérée comme non conforme si son taux d'échec de connexion est supérieur ou égal à 80 % pendant au moins 8 heures dans une plage de temps donnée par le passé.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

La configuration du nom de domaine d'origine OSS dans le nom de domaine CDN est anormale (Nouveau dans le modèle 3.0)

Si la configuration du nom de domaine d'origine dans un nom de domaine CDN n'existe pas, les demandes de ressources échouent, ce qui affecte les fonctions métier. Parallèlement, l'échec de la récupération à l'origine pousse le CDN à réessayer continuellement, augmentant ainsi la surcharge réseau inutile. Un nom de domaine CDN est considéré comme non conforme s'il utilise un nom de domaine OSS dans ses informations d'origine et que le statut de la resource du bucket OSS correspondant n'est pas « In Use ». Les noms de domaine CDN qui n'utilisent pas de nom de domaine OSS comme information d'origine ne sont pas inclus dans le périmètre de détection.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

Le nom de domaine OSS configuré dans l'enregistrement CNAME de la résolution de nom de domaine DNS est anormal (Nouveau dans le modèle 3.0)

Si un nom de domaine OSS incorrect est configuré dans l'enregistrement CNAME de la résolution de nom de domaine DNS, l'accès aux ressources via ce nom de domaine entraîne un échec de chargement des ressources, ce qui perturbe les fonctions métier normales. Un nom de domaine DNS est considéré comme non conforme si un enregistrement CNAME DNS est configuré avec un nom de domaine OSS et que le bucket OSS correspondant n'est pas « In Use ». Les noms de domaine DNS qui n'utilisent pas de nom de domaine OSS dans leurs enregistrements CNAME ne sont pas inclus dans le périmètre de détection.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'image personnalisée configurée dans le modèle de lancement d'instance ECS est anormale (Nouveau dans le modèle 3.0)

Un modèle de lancement d'instance est un outil permettant de créer rapidement des instances, améliorant ainsi l'efficacité et l'expérience utilisateur. Lorsque l'image personnalisée configurée dans le modèle de lancement n'existe pas, l'exécution du modèle de lancement échoue. Un modèle de lancement d'instance ECS est considéré comme non conforme si l'image personnalisée qui lui est associée n'est pas une resource « In Use ».

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'équilibreur de charge associé au groupe de mise à l'échelle ESS est anormal (Nouveau dans le modèle 3.0)

Une fois qu'un groupe de mise à l'échelle est associé à une instance d'équilibreur de charge, que le groupe crée automatiquement des instances ou que des instances y soient ajoutées manuellement, ces instances sont automatiquement ajoutées aux serveurs backend de l'instance d'équilibreur de charge. Si l'équilibreur de charge ou le groupe de serveurs de l'équilibreur de charge n'existe pas, le groupe de mise à l'échelle ne peut pas effectuer de mise à l'échelle. Un groupe Auto Scaling est considéré comme non conforme si le Classic Load Balancer ou l'Application Load Balancer qui lui est associé n'est pas une resource « In Use ».

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

Le délai entre l'instance RDS en lecture seule et l'instance principale est trop important (Nouveau dans le modèle 3.0)

Une instance RDS en lecture seule utilise la technologie native de réplication basée sur les journaux de MySQL (réplication asynchrone ou semi-synchrone), ce qui implique inévitablement une latence de synchronisation. Cette latence provoque une incohérence des données entre l'instance en lecture seule et l'instance principale, entraînant des problèmes métier. De plus, la latence peut provoquer une accumulation des journaux, consommant rapidement l'espace de l'instance en lecture seule. Une instance RDS en lecture seule est considérée comme non conforme si le délai maximal entre celle-ci et l'instance principale dépasse 60 secondes sur une période de 7 jours.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

Nombre insuffisant d'adresses IP disponibles dans l'instance VPC (Nouveau dans le modèle 3.0)

Assurez-vous que le vSwitch du VPC dispose d'un nombre suffisant d'adresses IP disponibles pour éviter de ne pas pouvoir étendre l'activité en raison d'un manque de ressources. Un vSwitch VPC est considéré comme non conforme si le nombre d'adresses IPv4 disponibles est inférieur ou égal à une valeur spécifiée (la valeur par défaut est 10).

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'instance ECS a été arrêtée en raison d'un retard de paiement ou d'une interdiction de sécurité

L'arrêt passif d'une instance ECS provoque une interruption de service, une perte de données et une incohérence des données, affectant les performances du système ou créant des risques de sécurité. Un compte est considéré comme présentant un risque s'il contient une instance ECS arrêtée en raison d'un retard de paiement ou d'une interdiction de sécurité.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que le statut backend de l'instance CLB de l'API Server est anormal (Nouveau dans le modèle 3.0)

Si le statut backend de l'instance CLB de l'API Server d'un cluster ACK est anormal, la communication du plan de contrôle est interrompue, ce qui entraîne directement un échec total de la gestion du cluster. Les clients tels que kubectl ne peuvent pas accéder à l'API Server, rendant impossibles des opérations telles que le déploiement d'applications et la consultation du statut. Parallèlement, des composants tels que kubelet et les contrôleurs déclenchent des statuts de nœud anormaux, des échecs d'ordonnancement des Pods et des défaillances des mécanismes de récupération automatique en raison de la déconnexion de l'API Server. Cela provoque ensuite l'effondrement de la stabilité du cluster et l'interruption des services métier dus à l'inaccessibilité de l'API. En outre, les outils de surveillance tels que Prometheus ne peuvent pas collecter les données de métriques, rendant impossible l'alerte rapide et le dépannage des anomalies. Plus grave encore, l'indisponibilité prolongée de l'API Server peut provoquer une incohérence entre l'état du cluster et les données stockées dans etcd, conduisant à une perte de données ou à des anomalies opérationnelles. La configuration du CLB, l'état de santé des nœuds backend et la connectivité réseau doivent être vérifiés immédiatement pour assurer une distribution normale du trafic et éviter un crash complet du cluster. Un cluster ACK est considéré comme non conforme si le statut backend de son instance CLB d'API Server est anormal.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que l'APIService est indisponible (Nouveau dans le modèle 3.0)

Si un APIService d'un cluster ACK est indisponible, la fonction d'API étendue échoue. Les resources personnalisées telles que les CRD ne peuvent pas communiquer avec le plan de contrôle, ce qui entraîne des anomalies de gestion pour les composants dépendant des API étendues, tels que les Opérateurs et les maillages de services. Les requêtes API telles que les mises à jour de statut de resource et la diffusion de configuration échouent en raison de l'interruption du service, ce qui peut provoquer une perte de données de surveillance, l'échec de politiques automatiques ou des erreurs de commandes de gestion du cluster. Si des API étendues essentielles telles que les Webhooks d'admission sont affectées, cela bloque le processus de création de resources, aggravant le risque de blocage des opérations du cluster. L'APIService doit être restauré d'urgence pour éviter la paralysie des fonctions clés et l'incohérence des données. Un cluster ACK est considéré comme non conforme si son APIService est indisponible.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que le mode de facturation du service LoadBalancer est incohérent avec l'instance réelle (Nouveau dans le modèle 3.0)

Si le mode de facturation d'un service LoadBalancer d'un cluster ACK ne correspond pas à l'instance réelle, cela provoque des anomalies de facturation. Cela peut conduire à une livraison inattendue, par exemple un paiement à l'utilisation au lieu de l'abonnement prévu, ou à une libération inattendue de resources, comme le non-renouvellement d'un abonnement à son expiration, provoquant une interruption de service. Parallèlement, une gestion chaotique des resources interfère avec les politiques de mise à l'échelle automatique, augmentant les coûts et les risques O&M. La configuration du mode de facturation doit être calibrée immédiatement pour éviter les écarts de facturation et la baisse de disponibilité de l'activité. Un cluster ACK est considéré comme non conforme si le mode de facturation de son service LoadBalancer est incohérent avec l'instance réelle.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que l'ID d'instance de certificat du service LoadBalancer est incohérent avec l'instance réelle (Nouveau dans le modèle 3.0)

Si l'ID d'instance de certificat d'un service LoadBalancer d'un cluster ACK ne correspond pas au certificat réellement lié, la configuration TLS échoue. Cela entraîne le rejet des connexions au service HTTPS ou des avertissements de sécurité, ainsi que l'interruption de l'accès utilisateur. Un certificat invalide peut exposer du trafic non chiffré, augmentant le risque d'attaques de l'homme du milieu. Parallèlement, des contrôles de santé anormaux jugent mal l'état des services backend, aggravant le chaos dans la distribution du trafic. La configuration du certificat doit être synchronisée immédiatement pour rétablir une communication sécurisée et la disponibilité du service. Un cluster ACK est considéré comme non conforme si l'ID d'instance de certificat de son service LoadBalancer est incohérent avec l'instance réelle.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle un Pod CoreDNS anormal (Nouveau dans le modèle 3.0)

Un Pod CoreDNS anormal dans un cluster ACK rend le service de résolution DNS instable. La communication entre les services via des noms de domaine peut expirer ou échouer, entraînant des interruptions d'appels d'application. Un Pod anormal peut déclencher des redémarrages continus par le contrôleur, augmentant la charge sur le plan de contrôle et occupant les resources du nœud sans fournir de services efficaces. Si le Pod est anormal en raison d'erreurs de configuration ou de vulnérabilités d'image, cela peut provoquer un détournement DNS ou une pollution de résolution, conduisant à des erreurs de routage de service ou à des fuites de données. Le statut du Pod doit être vérifié et la configuration réparée immédiatement pour rétablir la fiabilité du service DNS. Un cluster ACK est considéré comme non conforme s'il contient un Pod CoreDNS anormal.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que le statut du composant élastique est anormal (Nouveau dans le modèle 3.0)

Si le statut du composant élastique d'un cluster ACK est anormal, des mécanismes tels que la mise à l'échelle automatique et la récupération automatique après incident échouent. Le cluster ne peut pas monter en charge dynamiquement lors de charges élevées, ce qui entraîne des goulots d'étranglement des resources, des retards de réponse des services ou des interruptions. Il ne peut pas remplacer automatiquement les nœuds ou Pods défectueux, aggravant les risques de disponibilité. Parallèlement, le cluster ne peut pas optimiser l'allocation des resources selon les politiques, ce qui résulte en un gaspillage de coûts ou une baisse d'efficacité O&M. À long terme, cela peut bloquer des processus métier clés. Le statut du composant élastique doit être réparé d'urgence pour restaurer les capacités d'adaptation du cluster. Un cluster ACK est considéré comme non conforme si le statut de son composant élastique est anormal.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que le vSwitch du pool de nœuds est indisponible (Nouveau dans le modèle 3.0)

Si le vSwitch d'un pool de nœuds d'un cluster ACK est indisponible, la communication réseau entre les nœuds est interrompue. Les Pods et les services ne peuvent pas interagir entre les nœuds, ce qui entraîne des échecs de découverte de services ou une stagnation de la transmission des données. La communication entre le plan de contrôle et les nœuds de travail est coupée, et les nœuds sont marqués comme indisponibles, ce qui peut déclencher des évictions erronées ou une réduction anormale de la taille du cluster. Parallèlement, les nœuds ne peuvent pas accéder au stockage externe, aux bases de données et à d'autres resources, ce qui paralyse les fonctions des applications. Le risque de partitionnement réseau est aggravé, pouvant provoquer un split-brain du cluster ou une incohérence des données. Du point de vue O&M, il devient impossible de localiser les pannes en temps opportun en raison de l'interruption des données de surveillance. Le service vSwitch doit être restauré d'urgence pour garantir la connectivité réseau. Un cluster ACK est considéré comme non conforme si le vSwitch de son pool de nœuds est indisponible.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que le groupe de mise à l'échelle du pool de nœuds est indisponible (Nouveau dans le modèle 3.0)

Si le groupe de mise à l'échelle d'un pool de nœuds d'un cluster ACK est indisponible, le cluster perd totalement ses capacités de mise à l'échelle automatique. Il ne peut pas monter en charge dynamiquement lors de charges élevées, ce qui entraîne l'épuisement des resources des nœuds, des échecs d'ordonnancement des Pods ou des retards de réponse des services. Il ne peut pas réduire sa capacité lors de faibles charges, ce qui résulte en une inactivité des resources et un gaspillage de coûts. Le mécanisme de remplacement automatique des nœuds défectueux échoue, pouvant laisser des nœuds hors ligne pendant une longue période et aggravant le risque de point de défaillance unique dans le cluster. Parallèlement, un groupe de mise à l'échelle anormal entrave la capacité du cluster à répondre élastiquement à un trafic soudain ou à des besoins de maintenance. À long terme, cela conduit à une baisse de la stabilité du service et de l'efficacité O&M. Le statut du groupe de mise à l'échelle doit être réparé immédiatement pour restaurer les capacités élastiques du cluster. Un cluster ACK est considéré comme non conforme si le groupe de mise à l'échelle de son pool de nœuds est indisponible.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que la configuration de mise à l'échelle du pool de nœuds est indisponible (Nouveau dans le modèle 3.0)

Si la configuration de mise à l'échelle d'un pool de nœuds d'un cluster ACK est indisponible, le cluster ne peut pas ajuster automatiquement le nombre de nœuds. Il ne peut pas monter en charge lors de charges élevées, ce qui entraîne l'épuisement des resources, des échecs d'ordonnancement des Pods ou des interruptions de service. Il ne peut pas réduire sa capacité lors de faibles charges, ce qui résulte en un gaspillage de resources et une flambée des coûts. Parallèlement, le mécanisme de remplacement automatique des nœuds défectueux échoue, pouvant rendre des nœuds indisponibles pendant une longue période et réduisant la haute disponibilité du cluster. À long terme, cela provoque également l'échec de politiques automatiques telles que HPA (Horizontal Pod Autoscaler), conduisant à un état déséquilibré du cluster et à une augmentation des coûts O&M. La configuration de mise à l'échelle doit être réparée immédiatement pour restaurer les capacités élastiques. Un cluster ACK est considéré comme non conforme si la configuration de mise à l'échelle de son pool de nœuds est indisponible.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'inspection du cluster ACK révèle que le groupe de sécurité du pool de nœuds est indisponible (Nouveau dans le modèle 3.0)

Si le groupe de sécurité d'un pool de nœuds d'un cluster ACK est indisponible, les règles d'accès réseau échouent. La communication entre les composants du cluster tels que kubelet et l'API Server, ainsi que la découverte de services entre Pods, peuvent être interrompues en raison du blocage de ports ou de l'absence de règles. Parallèlement, un trafic non autorisé peut franchir la protection, augmentant le risque d'intrusion sur les nœuds ou d'attaques DDoS. Si les règles sortantes sont anormales, les nœuds ne peuvent pas accéder au stockage externe, aux référentiels d'images ou aux services de surveillance, ce qui entraîne des échecs d'appels de services dépendants. La défaillance du groupe de sécurité provoque également l'isolement erroné des nœuds, affectant l'ordonnancement des Pods et la continuité de l'activité. La configuration des règles doit être réparée immédiatement pour restaurer l'isolation réseau et la sécurité des communications. Un cluster ACK est considéré comme non conforme si le groupe de sécurité de son pool de nœuds est indisponible.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

Le taux d'erreurs 4xx de l'ALB est trop élevé (Nouveau dans le modèle 3.0)

Si le taux d'erreurs 4xx d'une instance ALB dépasse continuellement un seuil spécifié pendant une certaine période, cela signifie généralement qu'il y a de nombreuses exceptions dans les requêtes client, telles que des requêtes invalides, des erreurs de paramètres, des échecs d'authentification ou une fréquence d'accès élevée comme lors d'attaques DDoS. Cela affecte non seulement l'expérience des utilisateurs normaux, mais peut aussi exposer des défauts de conception d'interface système ou des risques de sécurité. Une instance ALB est considérée comme non conforme si son taux d'erreurs 4xx est supérieur ou égal à 80 % pendant au moins 8 heures dans une plage de temps donnée par le passé.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'instance CEN n'est pas configurée avec un contrôle de santé VBR (Nouveau dans le modèle 3.0)

La fonctionnalité de contrôle de santé de Cloud Enterprise Network détecte la connectivité du circuit Express Connect associé à une instance VBR. Dans les scénarios où il existe des routes redondantes entre Cloud Enterprise Network et un centre de données, le contrôle de santé permet de basculer automatiquement vers une route disponible après la détection d'une défaillance du circuit Express Connect, garantissant ainsi une transmission ininterrompue du trafic. Une instance CEN est considérée comme non conforme si un VBR qui lui est associé n'est pas configuré avec un contrôle de santé.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'enregistrement SPF dans la résolution d'e-mail de domaine DNS est anormal (Nouveau dans le modèle 3.0)

SPF est un protocole de validation d'e-mail basé sur DNS utilisé pour définir quels serveurs de messagerie (adresses IP ou noms de domaine) sont autorisés à envoyer des e-mails au nom d'un domaine. Lorsqu'un serveur de messagerie reçoit un e-mail, il vérifie l'adresse IP de l'expéditeur par rapport à la liste autorisée dans l'enregistrement SPF pour déterminer si l'e-mail est légitime. Définir une valeur SPF valide et raisonnable permet d'éviter l'usurpation d'e-mails, de réduire le risque de spam et d'améliorer le taux de livraison des e-mails. Pour chaque enregistrement MX d'un domaine DNS, vérifiez s'il existe au moins un enregistrement TXT avec une valeur SPF valide commençant par v=spf1. Un domaine DNS qui ne remplit pas les conditions ci-dessus est considéré comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

L'instance ECS a des événements O&M en attente

Ne pas répondre et traiter en temps opportun les événements O&M planifiés pour ECS peut provoquer le redémarrage de l'instance ECS pendant les heures de pointe de l'activité, affectant la stabilité des services sur l'instance ECS. Un compte est considéré comme présentant un risque s'il existe des événements O&M ECS en attente avec un statut « Inquiring », « Scheduled » ou « Executing ».

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

Le bucket OSS n'est pas configuré avec un nom de domaine personnalisé

L'utilisation d'un nom de domaine personnalisé peut améliorer l'image de marque, le professionnalisme et la stabilité. Un nom de domaine personnalisé peut être lié via CNAME pour permettre l'accélération CDN, améliorant ainsi les performances d'accès. Il prend également en charge l'accès sécurisé HTTPS, renforçant la sécurité de la transmission des données. Un bucket OSS est considéré comme non conforme s'il n'est pas configuré avec un nom de domaine personnalisé.

La correction rapide n'est pas prise en charge.

Non

Inspection des risques

La réplication des données pour l'instance RDS for PostgreSQL n'utilise pas le mode synchrone ou semi-synchrone (Nouveau dans le modèle 3.0)

RDS for PostgreSQL prend en charge trois modes de réplication des données : asynchrone, synchrone et semi-synchrone. Le mode asynchrone offre la vitesse de réponse la plus rapide, mais convient uniquement aux scénarios ayant de faibles exigences de persistance des données. Une perte de données peut survenir en cas de crash de la base de données, posant un risque de persistance. Une instance RDS for PostgreSQL est considérée comme non conforme si elle utilise le mode asynchrone pour la réplication des données (le paramètre synchronous_commit est désactivé).

Cette correction change le mode de réplication des données de la base de données RDS for PostgreSQL en mode semi-synchrone ou synchrone. Le mode synchrone offre le niveau de protection maximal et convient aux scénarios ayant des exigences de persistance des données extrêmement élevées, mais la vitesse de réponse est lente. Le mode semi-synchrone offre le niveau de protection de disponibilité le plus élevé, équilibrant persistance des données et vitesse de réponse. Pour changer le mode de réplication des données en semi-synchrone, la version du noyau de l'instance doit être 20220228 ou ultérieure. L'action de modification du paramètre est exécutée dans la fenêtre de maintenance définie pour l'instance.

Non

Inspection des risques

L'utilisation des connexions de l'instance Redis est trop élevée (Nouveau dans le modèle 3.0)

Si l'utilisation des connexions d'une instance Redis dépasse continuellement un seuil spécifié pendant une certaine période, cela indique que les resources de connexion actuelles sont proches ou ont atteint leur limite. Cela peut empêcher les nouveaux clients d'établir des connexions, provoquer le rejet de requêtes ou augmenter la latence de réponse, affectant ainsi les performances et la stabilité de l'activité. Cette situation peut également indiquer des problèmes tels que des fuites de connexions, des configurations de pool de connexions inadéquates ou une pression soudaine du trafic. Une instance Redis est considérée comme non conforme si son utilisation moyenne des connexions est supérieure ou égale à 50 % pendant au moins 8 heures dans une plage de temps donnée par le passé.

La correction rapide n'est pas prise en charge.

Non

Sauvegarde des données et snapshots

La sauvegarde des journaux n'est pas activée pour l'instance AnalyticDB for MySQL

Un cluster AnalyticDB for MySQL est considéré comme non conforme si la sauvegarde des journaux n'est pas activée.

Cette correction active la sauvegarde des journaux pour le cluster AnalyticDB for MySQL sélectionné, avec une période de rétention par défaut de 7 jours.

Non

Sauvegarde des données et snapshots

Aucun jeu de sauvegarde de données disponible pour l'instance AnalyticDB for PostgreSQL (Nouveau dans le modèle 3.0)

Le contrôle de sauvegarde des données pour AnalyticDB for PostgreSQL vise à garantir que l'instance dispose d'un jeu de sauvegarde disponible pour prévenir les interruptions d'activité causées par une perte de données ou une mauvaise manipulation. En vérifiant périodiquement la politique de sauvegarde et l'état des sauvegardes, vous pouvez améliorer efficacement la sécurité des données et les capacités de récupération. Une instance de stockage AnalyticDB for PostgreSQL en cours d'exécution et de type non Serverless est considérée comme non conforme si elle ne dispose d'aucun jeu de sauvegarde de données disponible dans un nombre d'heures spécifié par le passé (par défaut 7 jours ou 168 heures).

Une fois cette option activée, l'instance AnalyticDB for PostgreSQL effectue des sauvegardes de données selon la configuration de sauvegarde, générant ainsi un jeu de sauvegarde disponible. AnalyticDB for PostgreSQL peut restaurer une nouvelle instance à un point historique dans le temps grâce à une sauvegarde de base complète et des sauvegardes de journaux continues, garantissant ainsi la sécurité des données à ce moment-là.

Non

Sauvegarde des données et snapshots

La protection des sauvegardes de données pour l'instance ECS est à risque (Nouveau dans le modèle 3.0)

Différentes solutions de snapshot et de sauvegarde doivent être sélectionnées pour différents scénarios, tels que la protection quotidienne des données, l'accompagnement d'opérations à haut risque, la protection contre les sinistres régionaux et la récupération complète de la machine. Sinon, il peut être impossible de récupérer les données, et une solution de sauvegarde incomplète conduit à une récupérabilité et une efficacité des fichiers essentiels ne répondant pas aux attentes. Une instance ECS est considérée comme non conforme si elle n'a activé aucune des solutions de sauvegarde suivantes : 1. Activer la solution de snapshot de disque cloud. 2. Configurer la solution de sauvegarde « File/Self-managed Database Backup ».

La correction rapide n'est pas prise en charge.

Non

Sauvegarde des données et snapshots

Aucune politique de snapshot automatique n'est définie pour le disque ECS

Un disque ECS est considéré comme non conforme si aucune politique de snapshot automatique n'est définie pour celui-ci.

Cette correction active la politique de snapshot spécifiée pour l'instance de disque ECS sélectionnée. Étant donné que les politiques de snapshot sont indépendantes dans chaque région, si une politique portant le même nom existe dans la région où se trouve le disque sélectionné, la politique existante est utilisée. Sinon, une nouvelle politique de snapshot est créée.

Non

Sauvegarde des données et snapshots

La sauvegarde des journaux n'est pas activée pour l'instance MongoDB

Une instance MongoDB est considérée comme non conforme si la sauvegarde des journaux n'est pas activée.

Cette correction active la sauvegarde des journaux pour le cluster MongoDB sélectionné, avec une période de rétention par défaut de 7 jours.

Non

Sauvegarde des données et snapshots

La politique de sauvegarde des données pour le système de fichiers NAS est à risque (Nouveau dans le modèle 3.0)

Si la corbeille NAS et Cloud Backup ne sont pas activés, vous ne pouvez pas récupérer vos fichiers à temps en cas de suppression accidentelle ou de falsification. Si la réplication interrégionale n'est pas activée pour le coffre-fort de sauvegarde, la géo-redondance multiversion ne peut pas être atteinte, et les données ne peuvent pas être restaurées dans un autre emplacement, ce qui affecte gravement la continuité de l'activité. Un système de fichiers NAS est considéré comme non conforme s'il n'a activé aucune des solutions de sauvegarde suivantes : 1. Activer la corbeille NAS. 2. Activer la sauvegarde NAS.

Cette correction active la fonctionnalité de corbeille NAS. Pour éviter les perturbations d'activité ou la perte permanente de données causées par la suppression accidentelle de fichiers dans un système de fichiers NAS à usage général, nous vous recommandons d'activer la fonctionnalité de corbeille. Une fois activée, les fichiers ou répertoires supprimés sont temporairement stockés dans la corbeille et sont définitivement supprimés après la période de rétention spécifiée. Vous pouvez restaurer ces fichiers et leurs informations de métadonnées telles que UID, GID et ACL pendant la période de rétention.

Non

Sauvegarde des données et snapshots

La politique de sauvegarde des données pour le bucket OSS est à risque

Les données au niveau du bucket doivent être protégées. Si le versionning n'est pas activé, les versions historiques des opérations de remplacement et de suppression de données peuvent ne pas être enregistrées. En cas de problème, il est impossible de restaurer l'objet stocké dans le bucket à un point spécifique dans le temps. Parallèlement, si la réplication interrégionale n'est pas activée, les opérations sous le même compte ou sous des comptes différents ne sont pas synchronisées vers une autre région. Lorsqu'un sinistre ou une panne survient, cela nuit gravement à la continuité de l'activité. Un bucket OSS est considéré comme non conforme s'il n'a pas activé au moins l'une des solutions de sauvegarde suivantes : 1. Activer le versionning OSS. 2. Activer la sauvegarde de bucket OSS.

Cette correction active le versionning pour l'instance OSS sélectionnée. Une fois le versionning activé, les opérations de remplacement et de suppression de données sont enregistrées en tant que versions historiques. Si vous écrasez ou supprimez accidentellement un objet, vous pouvez restaurer l'objet stocké dans le bucket vers n'importe quelle version historique à tout moment.

Non

Sauvegarde des données et snapshots

La sauvegarde de niveau 2 n'est pas activée pour le cluster PolarDB

Un cluster PolarDB est considéré comme non conforme si la sauvegarde de niveau 2 n'est pas activée et que la période de rétention est supérieure ou égale à 30.

Cette correction définit le cycle de sauvegarde de niveau 2 et la période de rétention de la sauvegarde de niveau 2 (par défaut 30 jours) pour le cluster PolarDB sélectionné. Si la sauvegarde de niveau 2 n'est pas actuellement activée, elle est automatiquement activée.

Non

Sauvegarde des données et snapshots

La sauvegarde des journaux n'est pas activée pour l'instance RDS

Une instance RDS est considérée comme non conforme si la sauvegarde des journaux n'est pas activée.

Cette correction active la sauvegarde des journaux pour l'instance RDS sélectionnée, avec une période de rétention par défaut de 7 jours.

Non

Sauvegarde des données et snapshots

La politique de sauvegarde des données pour l'instance Tablestore est à risque (Nouveau dans le modèle 3.0)

Si la sauvegarde Tablestore et la sauvegarde interrégionale ne sont pas activées, les données importantes ne peuvent pas être restaurées rapidement de manière simple, efficace, sûre et fiable. En cas de panne, la continuité de l'activité est gravement affectée. Une instance Tablestore est considérée comme non conforme si aucune solution de sauvegarde n'est activée.

La correction rapide n'est pas prise en charge.

Non

Sauvegarde des données et snapshots

Le pod d'instance élastique ECI n'a aucun volume de données monté

Un pod d'instance élastique ECI est considéré comme non conforme s'il n'a aucun volume de données monté.

La correction rapide n'est pas prise en charge.

Non

Sauvegarde des données et snapshots

La sauvegarde automatique n'est pas activée pour l'instance Elasticsearch

Une instance Elasticsearch est considérée comme non conforme si la sauvegarde automatique n'est pas activée.

L'exécution de cette opération active la fonctionnalité de sauvegarde automatique pour l'instance Elasticsearch sélectionnée. Le système sauvegarde automatiquement les données selon le cycle et l'heure de sauvegarde définis. Si des données sont supprimées accidentellement ou s'il y a une erreur logique dans l'application, vous pouvez utiliser la fonctionnalité de récupération de sauvegarde automatique pour restaurer les données de sauvegarde d'un point spécifique dans le temps vers l'instance ES d'origine, garantissant ainsi la sécurité des données. Notez que les sauvegardes automatiques ne conservent les données de snapshot que pour les 7 derniers jours, et les données de sauvegarde automatique ne peuvent être utilisées que pour restaurer le cluster d'origine.

Non

Sauvegarde des données et snapshots

La sauvegarde incrémentielle n'est pas définie pour l'instance Redis

Une instance Redis (Tair Enterprise Edition) est considérée comme non conforme si la sauvegarde incrémentielle n'est pas activée.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Le cluster ACK présente un risque de déploiement monozones

L'utilisation d'un cluster régional permet d'obtenir des capacités de reprise après sinistre interrégionales. Un cluster ACK est conforme s'il s'agit d'un cluster régional avec des nœuds répartis dans 3 zones ou plus.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance ALB présente un risque de déploiement monozones

Si une seule zone est sélectionnée, cela affecte l'instance ALB lorsque cette zone tombe en panne, impactant la stabilité de l'activité. Une instance ALB est conforme s'il s'agit d'une instance multizone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Les resources montées sur le groupe de serveurs ALB sont toutes dans une seule zone

L'ajout de resources provenant de plusieurs zones à un groupe de serveurs d'équilibreur de charge ALB permet de garantir que même si une zone tombe en panne, l'application peut toujours fonctionner dans d'autres zones, offrant ainsi une meilleure tolérance aux pannes. Un groupe de serveurs d'équilibreur de charge ALB est conforme si les resources qui y sont montées sont réparties sur plusieurs zones. Cette règle ne s'applique pas si le groupe de serveurs ALB n'a aucune resource montée ou si le groupe de serveurs est de type IP ou Function Compute.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance API Gateway présente un risque de déploiement monozones

Nous vous recommandons d'utiliser une instance API Gateway multizone, qui dispose de capacités de reprise après sinistre multizone. Une instance de passerelle est conforme si elle est multizone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

La distribution des instances ECS dans une région est déséquilibrée entre les zones (Nouveau dans le modèle 3.0)

Déployer toutes les instances ECS dans la même zone pose un risque de point de défaillance unique. Lorsque cette zone tombe en panne en raison de dommages matériels, d'une interruption réseau ou d'autres problèmes, toutes les instances ECS de cette région deviennent indisponibles simultanément, ce qui entraîne une interruption de l'activité. Un compte est considéré comme non conforme si toutes les instances ECS d'une même région sont déployées dans la même zone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance Flink n'utilise pas un type CU interzone

Nous vous recommandons d'activer l'interzone pour les CU Flink, ce qui offre des capacités de reprise après sinistre multizone. Une instance Flink est considérée comme non conforme si elle n'utilise pas de CU multizone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance GWLB présente un risque de déploiement monozones

Nous vous recommandons d'activer le multizone pour les instances GWLB, ce qui offre des capacités de reprise après sinistre multizone. Une instance Gateway Load Balancer est considérée comme non conforme si elle n'est pas multizone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Les resources montées sur le groupe de serveurs GWLB sont toutes dans une seule zone (Nouveau dans le modèle 3.0)

Monter des resources dans un groupe de serveurs multizone peut améliorer les capacités de reprise après sinistre du système et réduire le risque d'interruption de l'activité. Un compte est considéré comme non conforme si une instance GWLB est monozones, ou si un groupe de serveurs utilisé par un écouteur sous une instance GWLB n'a pas ajouté de resources provenant de plusieurs zones. Cette règle ne s'applique pas lorsqu'il n'y a aucune resource dans le groupe de serveurs ou si le type de resource est IP.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Les composants liés à MSE présentent un risque de déploiement monozones

Nous vous recommandons d'adopter une architecture de déploiement multizone pour les composants liés à MSE afin d'améliorer leur stabilité. Un composant lié à MSE est considéré comme non conforme s'il est déployé dans une seule zone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

La passerelle MSE présente un risque de déploiement monozones

Toutes les réplicas d'instance de la passerelle actuelle sont déployées dans la même zone (AZ). Cette forme de déploiement ne possède pas de capacités de haute disponibilité, et votre activité peut être endommagée dans des cas extrêmes. Mettez à niveau vers la nouvelle version dès que possible pour disperser les instances de passerelle sur plusieurs zones. Un composant de passerelle MSE Ingress est considéré comme non conforme s'il possède une architecture monozones.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance MongoDB présente un risque de déploiement monozones

L'utilisation d'une instance MongoDB qui n'est pas multizone est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance NLB présente un risque de déploiement monozones

Pour les instances Network Load Balancer, il est fortement recommandé de configurer le multizone pour répondre aux exigences de reprise après sinistre multizone. L'utilisation d'une instance Network Load Balancer monozones est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Les resources montées sur le groupe de serveurs NLB sont toutes dans une seule zone

Nous vous recommandons d'ajouter des resources provenant de plusieurs zones à un groupe de serveurs Network Load Balancer, ce qui offre des capacités de reprise après sinistre multizone. Un groupe de serveurs Network Load Balancer est conforme si ses resources sont réparties sur plusieurs zones. Cela ne s'applique pas s'il n'y a aucune resource dans le groupe de serveurs ou si le type de resource est IP.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Le stockage redondant interzone n'est pas activé pour le bucket OSS

Un bucket OSS est considéré comme non conforme si le stockage redondant interzone n'est pas activé.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Le cluster de stockage de secours à chaud n'est pas activé pour le cluster PolarDB

Un cluster PolarDB est considéré comme non conforme si un cluster de stockage de secours à chaud n'est pas activé et que les données sont réparties dans une seule zone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Le service d'endpoint PrivateLink présente un risque de déploiement monozones

Configurer plusieurs zones pour un service d'endpoint peut réduire considérablement le risque d'interruption de service, distribuer le trafic plus uniformément pour éviter de surcharger une seule zone, et fournir un accès de proximité, ce qui réduit la latence réseau et améliore la vitesse d'accès. Configurer plusieurs zones pour un service d'endpoint est conforme.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance RDS présente un risque de déploiement monozones

L'utilisation d'une instance RDS qui n'est pas multizone est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance Redis présente un risque de déploiement monozones

L'utilisation d'une instance Redis qui n'est pas multizone est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance SLB et le groupe de serveurs de son écouteur présentent un risque de point de déploiement unique

Un compte est considéré comme non conforme si une instance SLB est monozones, ou si un groupe de serveurs utilisé par un écouteur sous une instance SLB n'a pas ajouté de resources provenant de plusieurs zones.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance ApsaraMQ for Kafka présente un risque de déploiement monozones

Lorsque vous utilisez une instance Professional Edition et que vous avez sélectionné uniquement un déploiement monozones lors du déploiement, vous pouvez mettre à niveau le cluster vers une architecture de déploiement multizone en modifiant la zone secondaire, ce qui renforce les capacités de reprise après sinistre du cluster. Une instance ApsaraMQ for Kafka est conforme si elle est multizone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Le routeur de transit présente un risque de déploiement monozones

Pour les routeurs de transit existants, il est fortement recommandé de configurer le multizone pour répondre aux capacités de reprise après sinistre multizone. Un routeur de transit est considéré comme non conforme si sa connexion VPC n'a configuré un vSwitch que dans une seule zone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance AnalyticDB for PostgreSQL présente un risque de déploiement monozones

Nous vous recommandons d'activer la reprise après sinistre interzone pour les instances AnalyticDB for PostgreSQL. Lorsque la zone principale tombe en panne, le système bascule automatiquement le nœud de la zone secondaire vers le nœud principal pour continuer à fournir des services et assurer la continuité de l'activité. Une instance AnalyticDB for PostgreSQL est considérée comme non conforme si la reprise après sinistre interzone n'est pas activée.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Le cluster ClickHouse présente un risque de déploiement monozones

Nous vous recommandons d'utiliser une instance de cluster ClickHouse multizone, qui dispose de capacités de reprise après sinistre multizone. Une instance de cluster ClickHouse multizone est conforme. Actuellement, seule la version communautaire est vérifiée pour l'architecture multizone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance HBase présente un risque de déploiement monozones

Nous vous recommandons d'adopter une architecture de déploiement multizone, qui offre des capacités de reprise après sinistre supérieures. Une instance HBase est considérée comme non conforme si elle n'adopte pas un déploiement multizone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance Lindorm présente un risque de déploiement monozones

Nous vous recommandons de déployer des instances Lindorm dans plusieurs zones. Les instances multizone ont des capacités de reprise après sinistre supérieures. Parallèlement, les instances Lindorm peuvent atteindre une forte cohérence des données entre plusieurs zones, et peuvent également retourner le résultat le plus rapide sous une cohérence éventuelle des données, ce qui améliore la qualité de service des activités en ligne. Une instance Lindorm est considérée comme non conforme si elle n'adopte pas un déploiement multizone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance PolarDB-X 2.0 présente un risque de déploiement monozones

Nous vous recommandons d'utiliser une instance PolarDB-X 2.0 multizone, qui dispose de capacités de reprise après sinistre multizone. Une instance PolarDB-X 2.0 avec une architecture multizone est conforme.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance Tablestore présente un risque de déploiement monozones

Une instance Tablestore est considérée comme non conforme si elle n'utilise pas un déploiement multizone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'inspection du cluster ACK révèle que CoreDNS n'a qu'une seule réplica (Nouveau dans le modèle 3.0)

Si CoreDNS d'un cluster ACK ne conserve qu'une configuration à réplica unique, il perd sa haute disponibilité. Lorsque le Pod tombe en panne, le service DNS est complètement interrompu, ce qui provoque l'échec de la résolution des noms de domaine de service au sein du cluster et entraîne l'interruption de la communication entre les applications. Une architecture à point unique ne peut pas tolérer les pannes de nœuds ou les opérations de maintenance. Le service peut être momentanément interrompu lors des mises à niveau ou des redémarrages, et le risque d'exploitation à long terme est aggravé. Le nombre de réplicas doit être augmenté immédiatement pour garantir la redondance et la stabilité du service. Un cluster ACK est considéré comme non conforme si son CoreDNS n'a qu'une seule réplica.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Le stockage redondant interzone n'est pas activé pour le bucket OSS associé à ACR

Nous vous recommandons d'utiliser une instance ACR Enterprise Edition et de l'associer à un bucket OSS pour lequel le stockage redondant interzone est activé. Un ACR est considéré comme non conforme s'il est associé à un bucket OSS avec stockage localement redondant.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Le cluster ACS présente un risque de déploiement monozones

Nous vous recommandons d'utiliser un cluster ACS régional multizone, qui dispose de capacités de reprise après sinistre multizone. Un cluster ACS est conforme s'il s'agit d'un cluster régional avec des nœuds répartis dans 3 zones ou plus.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance Elasticsearch présente un risque de déploiement monozones

L'utilisation d'une instance Elasticsearch qui n'est pas multizone est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Le projet SLS n'utilise pas le stockage redondant interzone

Simple Log Service propose deux types de redondance de stockage : le stockage localement redondant et le stockage redondant interzone. Ceux-ci couvrent les mécanismes de redondance des données d'une seule zone à plusieurs zones pour garantir la persistance et la disponibilité des données. Un projet de journal est conforme s'il utilise le stockage redondant interzone.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

VPN Gateway présente un risque de déploiement monozones

Pour les instances à tunnel unique existantes, il est fortement recommandé d'activer la haute disponibilité AZ dans la console et de configurer des tunnels doubles pour se connecter au pair. Un VPN est considéré comme non conforme s'il utilise une instance à tunnel unique.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

VPN Gateway n'utilise pas le mode double tunnel

Une connexion IPsec-VPN en mode double tunnel possède un tunnel principal et un tunnel secondaire. Si le tunnel principal tombe en panne, le trafic peut être transmis via le tunnel secondaire, ce qui améliore la haute disponibilité de la connexion IPsec-VPN. Un VPN Gateway double tunnel est conforme si les tunnels principal et secondaire sont tous deux connectés au pair.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

Bastionhost présente un risque de déploiement monozones

Nous vous recommandons d'utiliser l'édition Enterprise Dual-Engine ou SM-compliant de Bastionhost pour répondre aux capacités de reprise après sinistre multizone. L'utilisation de l'édition Basic de Bastionhost est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Architecture multizone

L'instance ApsaraMQ for RocketMQ n'utilise pas l'édition High-availability Cluster

Nous vous recommandons d'utiliser l'édition High-availability Cluster, qui dispose de capacités de reprise après sinistre multizone. Une instance ApsaraMQ for RocketMQ 5.0 est considérée comme non conforme si elle n'est pas multizone.

La correction rapide n'est pas prise en charge.

Non

Architecture de cluster

Le groupe de mise à l'échelle ESS est associé à un seul vSwitch

En associant plusieurs vSwitches, un groupe de mise à l'échelle peut améliorer la robustesse, la fiabilité et les performances globales de l'application, l'aidant ainsi à mieux répondre aux exigences métier. Si un vSwitch est inaccessible en raison de problèmes réseau ou d'autres conditions, le trafic utilisateur peut toujours accéder à l'application via d'autres vSwitches. Un groupe de mise à l'échelle est conforme s'il est associé à au moins deux vSwitches.

La correction rapide n'est pas prise en charge.

Non

Architecture de cluster

Les composants liés à MSE présentent un risque de point de déploiement unique

Pour le composant MSE ZooKeeper, nous vous recommandons d'effectuer une mise à l'échelle horizontale vers 3 nœuds ou plus. Pour le composant Nacos-ANS, nous vous recommandons d'effectuer une mise à l'échelle horizontale vers 3 nœuds ou plus. Un composant lié à MSE est considéré comme non conforme s'il est déployé sur un seul nœud.

La correction rapide n'est pas prise en charge.

Non

Architecture de cluster

La passerelle MSE présente un risque de point de déploiement unique

Une instance à nœud unique présente un risque architectural. Un point de défaillance unique rend le service indisponible. Nous vous recommandons d'effectuer une mise à l'échelle horizontale vers 2 nœuds ou plus. Un composant MSE Ingress est considéré comme non conforme s'il est déployé sur un seul nœud.

La correction rapide n'est pas prise en charge.

Non

Architecture de cluster

L'instance PolarDB présente un risque de point de déploiement unique

Une instance PolarDB est considérée comme non conforme si elle n'utilise pas l'édition Cluster ou l'édition Multi-master Cluster.

La correction rapide n'est pas prise en charge.

Non

Architecture de cluster

Le basculement automatique primaire/secondaire n'est pas activé pour l'instance RDS (Nouveau dans le modèle 3.0)

Lorsque le nœud principal d'une instance est anormal et inutilisable, ou lorsqu'il y a un risque potentiel dans l'instance et qu'une réparation d'urgence a été effectuée sur le nœud secondaire, RDS déclenche automatiquement un basculement primaire/secondaire, échangeant ainsi les nœuds principal et secondaire. Après le basculement, l'endpoint de l'instance reste inchangé, et l'application se connecte automatiquement au nouveau nœud principal (l'ancien nœud secondaire), garantissant ainsi la haute disponibilité de l'instance. Une instance RDS est considérée comme non conforme si la fonctionnalité de basculement automatique primaire/secondaire n'est pas activée.

Cette correction active la fonctionnalité de basculement automatique primaire/secondaire pour l'instance RDS. Lorsque le nœud principal de l'instance est anormal et inutilisable, ou lorsqu'il y a un risque potentiel dans l'instance et qu'une réparation d'urgence a été effectuée sur le nœud secondaire, RDS déclenche automatiquement un basculement primaire/secondaire, échangeant ainsi les nœuds principal et secondaire. Après le basculement, l'endpoint de l'instance reste inchangé, et l'application se connecte automatiquement au nouveau nœud principal (l'ancien nœud secondaire), garantissant ainsi la haute disponibilité de l'instance.

Non

Architecture de cluster

Les nœuds principal et secondaire du cluster RDS ne sont pas configurés avec la même taille d'instance (Nouveau dans le modèle 3.0)

Si les nœuds principal et secondaire d'un cluster RDS ne sont pas configurés avec la même taille d'instance, cela peut empêcher le nœud secondaire de prendre le relais correctement lorsque le nœud principal tombe en panne, entraînant des goulots d'étranglement des performances ou des interruptions de service. De plus, des spécifications d'instance différentes peuvent conduire à des inadéquations de resources, ce qui affecte l'efficacité de la synchronisation des données et la vitesse de récupération, réduisant ainsi les capacités de haute disponibilité et de reprise après sinistre du système. Détecter et garantir que les tailles des nœuds principal et secondaire sont identiques aide à améliorer la stabilité du système, à renforcer les capacités de basculement et à assurer la continuité de l'activité. Cela apporte une fiabilité et une contrôlabilité O&M supérieures aux clients. Un cluster RDS est considéré comme non conforme si ses nœuds principal et secondaire sont configurés avec des tailles d'instance différentes.

La correction rapide n'est pas prise en charge.

Non

Architecture de cluster

Les nœuds principal et secondaire du cluster RDS ne sont pas configurés avec le même type d'instance (Nouveau dans le modèle 3.0)

Si les nœuds principal et secondaire d'un cluster RDS ne sont pas configurés avec le même type d'instance, cela peut empêcher le nœud secondaire de prendre le relais correctement lorsque le nœud principal tombe en panne, entraînant des goulots d'étranglement des performances ou des interruptions de service. De plus, des spécifications d'instance différentes peuvent conduire à des inadéquations de resources, ce qui affecte l'efficacité de la synchronisation des données et la vitesse de récupération, réduisant ainsi les capacités de haute disponibilité et de reprise après sinistre du système. Détecter et garantir que les types des nœuds principal et secondaire sont identiques aide à améliorer la stabilité du système, à renforcer les capacités de basculement et à assurer la continuité de l'activité. Cela apporte une fiabilité et une contrôlabilité O&M supérieures aux clients. Un cluster RDS est considéré comme non conforme si ses nœuds principal et secondaire sont configurés avec des types d'instance différents.

La correction rapide n'est pas prise en charge.

Non

Architecture de cluster

Le mode haute fiabilité n'est pas utilisé pour Express Connect (Nouveau dans le modèle 3.0)

Utilisez le mode haute fiabilité d'Express Connect pour créer deux points d'accès dans la même région afin d'atteindre la redondance réseau, garantir la stabilité et la fiabilité de la transmission des données et répondre aux exigences de conformité. Un circuit Express Connect est considéré comme non conforme s'il a moins de 2 points d'accès dans la même région.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Capacité de stockage restante insuffisante pour l'instance RDS (Nouveau dans le modèle 3.0)

Une capacité de stockage restante insuffisante pour une instance RDS peut entraîner des échecs d'écriture dans la base de données, une dégradation des performances, voire des interruptions de service ou des risques de perte de données. Il est nécessaire d'étendre la capacité ou de nettoyer les données en temps opportun pour éviter les anomalies métier, garantir la stabilité de la base de données et améliorer la fiabilité et la prévoyance des O&M. Une instance RDS est considérée comme non conforme si elle a moins de 10 % de sa capacité de stockage restante pendant 1 heure quelconque sur une période de 7 jours.

Cette correction active la fonctionnalité d'extension automatique du stockage pour l'instance RDS. Une fois activée, l'espace de stockage est automatiquement étendu lorsqu'il atteint le seuil. L'instance n'a pas besoin d'être redémarrée pendant l'extension, et il n'y a aucun impact sur l'activité.

Non

Quota et capacité

Les appels API ACK sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les appels API ALB sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les appels API CDN sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les appels API ECS sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les appels API NAS sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les appels API PolarDB sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les appels API RDS sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les appels API Redis sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les appels API RocketMQ sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les appels API SLB sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les appels API VPC sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les appels API Cloud Enterprise Network (CEN) sont limités

Les appels API sont limités, ce qui entraîne des échecs d'appel et peut affecter la stabilité de l'activité. Un compte est considéré comme non conforme s'il y a eu des exceptions de limitation pour les appels API au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre total de clusters ACK approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre de clusters ACK atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre total d'instances ALB approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre total d'instances ALB atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre d'actualisations d'URL CDN approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre d'actualisations d'URL CDN atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre de noms de domaine accélérés pris en charge par CDN approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre de noms de domaine accélérés pris en charge par CDN atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre d'actualisations de répertoire CDN approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre d'actualisations de répertoire CDN atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre d'éléments de préchargement CDN approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre d'éléments de préchargement CDN atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre total de disques cloud EBS approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre total de disques cloud EBS atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour les vCPU des instances ECS par abonnement approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié aux vCPU des instances ECS par abonnement atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour les vCPU des instances spot ECS approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié aux vCPU des instances spot ECS atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour les vCPU des instances ECS à paiement à l'utilisation approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au quota vCPU des instances ECS à paiement à l'utilisation atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre total d'EIP approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre total d'EIP atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre total de groupes de mise à l'échelle ESS approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre total de groupes de mise à l'échelle ESS atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

Les composants liés à MSE présentent un risque de capacité

Assurez-vous que la capacité des resources reste dans une plage raisonnable. Si la limite de capacité est dépassée, cela peut entraîner des risques de stabilité. Un MSE est considéré comme non conforme s'il a une métrique associée dont la capacité est dépassée.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre d'entrées SNAT pouvant être conservées dans une NAT Gateway approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre d'entrées SNAT pouvant être conservées dans une NAT Gateway atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre d'EIP pouvant être liées à une NAT Gateway approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre d'EIP pouvant être liées à une NAT Gateway atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre total d'instances NLB approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre total d'instances NLB atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour les instances RDS à la demande approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié aux instances RDS à la demande atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre total de piles ROS approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre total de piles ROS atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre d'écouteurs conservés par une instance SLB approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre d'écouteurs conservés par une instance SLB atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre de serveurs pouvant être montés sur le backend d'une instance SLB approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre de serveurs pouvant être montés sur le backend d'une instance SLB atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre total d'instances SLB approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre total d'instances SLB atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre total de groupes de sécurité approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre total de groupes de sécurité atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre total d'interfaces réseau élastiques approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre total d'interfaces réseau élastiques (ENI) atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Quota et capacité

L'utilisation du quota pour le nombre total d'ensembles de déploiement approche de la limite supérieure (Nouveau dans le modèle 3.0)

Un quota de resources insuffisant peut restreindre les opérations de création, de modification ou d'extension des resources produit. Un compte est considéré comme non conforme lorsque l'élément de quota lié au nombre total d'ensembles de déploiement atteint 80 % de sa limite supérieure.

La correction rapide n'est pas prise en charge.

Non

Gestion de la surveillance

Des règles d'alerte de surveillance ne sont pas définies pour les resources de produits cloud

Atteindre une couverture complète de la surveillance des resources est la base et la clé pour garantir la continuité de l'activité. Définir des règles d'alerte pour les resources de produits cloud est un moyen nécessaire pour assurer la surveillance de ces resources. Un compte est considéré comme non conforme s'il existe des resources de produits cloud qui ne sont couvertes par aucune règle d'alerte.

Cette correction active automatiquement les règles d'alerte basées sur les meilleures pratiques pour les types de resources cloud qui ne sont pas configurés avec Cloud Monitor. Par défaut, les notifications sont envoyées aux destinataires des messages du type « Alibaba Cloud Account Alert Contact ». Confirmez que les paramètres sont corrects. Après l'activation, vous pouvez consulter l'état d'activation ou mettre à jour les paramètres d'alerte dans la fonctionnalité alerte en un clic de Cloud Monitor.

Non

Gestion de la surveillance

Des règles d'alerte haute priorité ne sont pas configurées dans ARMS

Configurer des règles d'alerte efficaces permet de garantir que vous êtes notifié en temps opportun lorsque le système métier ne répond pas aux conditions de fonctionnement attendues, afin que vous puissiez intervenir d'urgence à temps. Un compte est considéré comme non conforme si aucune règle d'alerte de niveau P1 n'est configurée pour la surveillance d'applications ou la surveillance Prometheus dans Alibaba Cloud ARMS, ou si aucune politique de notification correspondante n'est configurée.

La correction rapide n'est pas prise en charge.

Non

Gestion de la surveillance

Les alertes haute priorité dans ARMS ne sont pas traitées rapidement

La métrique MTTx (Temps moyen jusqu'à xx, par exemple MTTR : Temps moyen de récupération) peut servir de mesure importante de l'efficacité du traitement des alertes. Répondre rapidement aux alertes haute priorité peut améliorer efficacement l'efficacité de récupération des alertes et même des pannes, ce qui améliore la qualité de service du système métier. Un compte est considéré comme non conforme si aucune règle d'alerte de niveau P1 n'est configurée pour la surveillance d'applications ou la surveillance Prometheus, ou s'il existe des alertes dans Alibaba Cloud ARMS qui n'ont pas été résolues dans les 30 minutes (en attente de prise en charge, en cours ou résolues après plus de 30 minutes).

La correction rapide n'est pas prise en charge.

Non

Gestion de la surveillance

Les règles d'alerte avec alertes continues ne sont pas traitées rapidement

Les règles d'alerte qui restent continuellement en état d'alerte pendant une longue période constituent un problème nécessitant attention et gouvernance. Généralement, le problème doit être résolu dès que possible pour ramener la métrique de surveillance à un niveau normal, ou les règles d'alerte doivent être ajustées en fonction de la situation réelle pour éviter que de nombreux messages d'alerte ou la fatigue liée aux alertes n'interfèrent avec le travail normal de surveillance et d'O&M. Un compte est considéré comme non conforme si une règle d'alerte définie dans Cloud Monitor est restée continuellement en état d'alerte pendant plus de 24 heures.

La correction rapide n'est pas prise en charge.

Non

Gestion de la surveillance

La surveillance Prometheus n'est pas configurée pour le cluster ACK

Connecter un cluster ACK à la surveillance aide le personnel de développement et d'O&M à visualiser l'état de fonctionnement du système, y compris la couche d'infrastructure, la couche de performance des conteneurs, etc. Un cluster ACK est considéré comme non conforme si « Enable Alibaba Cloud Prometheus Monitoring » n'est pas configuré.

La correction rapide n'est pas prise en charge.

Non

Gestion de la surveillance

La surveillance d'applications n'est pas configurée pour le cluster ACK

Pour les applications distribuées et basées sur des microservices, vous pouvez vous connecter à ARMS Application Monitoring pour obtenir un traçage de bout en bout et une surveillance des performances en temps réel au niveau du code, aidant ainsi le personnel d'O&M à suivre l'état de santé des applications à tout moment. Une application est considérée comme non conforme si elle est déployée dans ACK ou ECS mais n'est pas connectée à ARMS Application Monitoring.

La correction rapide n'est pas prise en charge.

Non

Gestion de la surveillance

Recommandation d'une surveillance unifiée des resources sur plusieurs comptes Alibaba Cloud pour ARMS

En créant une instance d'agrégation globale, vous pouvez réaliser une surveillance unifiée sur plusieurs comptes. Un compte est considéré comme non conforme s'il n'utilise pas ARMS et n'a pas créé d'instance GlobalView.

La correction rapide n'est pas prise en charge.

Non

Catégorie

Point de contrôle

Description du point de contrôle

Description de la correction rapide

Prise en charge de l'aide à la décision

Surveillance des coûts

L'alerte de crédit disponible n'est pas activée pour le compte (Nouveau dans le modèle 3.0)

Si l'option « Available Credit Alert » n'est pas activée pour le compte dans le User Center, cela peut entraîner des risques tels que la suspension du service pour impayés, la perte de données ou des interruptions d'activité lorsque le solde du compte est épuisé. De plus, l'absence de mécanisme d'alerte peut provoquer des dépassements budgétaires, ce qui affecte la gestion du budget de l'entreprise et sa conformité financière. Un compte est considéré comme non conforme si l'option « Available Credit Alert » n'y est pas activée.

Cette correction active la fonctionnalité d'alerte de crédit disponible. Lorsque le crédit disponible de votre compte passe sous le seuil d'alerte, vous recevez une notification par SMS, e-mail et message interne adressé au contact du compte (pendant 5 jours consécutifs maximum).

Non

Optimisation du mode de facturation

Il est recommandé d'utiliser la facturation par abonnement ou d'ajouter des resource en paiement à l'utilisation à un savings plan pour les instance ECS

Nous recommandons d'utiliser la facturation par abonnement pour les resource utilisées de manière stable sur le long terme. En règle générale, le coût d'une instance ECS avec facturation par abonnement est inférieur à celui d'une instance en paiement à l'utilisation. Un savings plan est un plan de remise offrant un tarif préférentiel sur le paiement à l'utilisation en échange d'un engagement à utiliser un volume stable de resource pendant une période donnée. Si une instance ECS utilise le paiement à l'utilisation sans avoir souscrit à un savings plan, cette configuration n'est pas considérée comme une bonne pratique.

La correction rapide n'est pas prise en charge.

Non

Optimisation du mode de facturation

Il est recommandé d'utiliser la facturation par abonnement pour les instance RDS

Nous recommandons d'utiliser la facturation par abonnement pour les resource utilisées de manière stable sur le long terme. En règle générale, le coût d'une instance RDS avec facturation par abonnement est inférieur à celui d'une instance en paiement à l'utilisation. Une instance RDS utilisant le paiement à l'utilisation est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Le site ESA est dans un état anormal

Ce point de contrôle vérifie que le site est activé afin qu'ESA puisse fournir des services d'accélération et de protection. À défaut, cette configuration n'est pas considérée comme une bonne pratique d'optimisation des resource applicatives.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Faible utilisation des resource d'une instance ECS

Maintenir l'utilisation des resource des instance ECS à un niveau raisonnable sur la durée constitue un enjeu majeur de la gestion des coûts cloud. La plateforme cloud propose aux entreprises diverses spécifications d'instance ECS. Celles-ci doivent sélectionner les spécifications adaptées en fonction des cycles réels de leur activité afin de maîtriser les coûts. Si l'utilisation du CPU et de la mémoire d'une instance ECS reste inférieure à 3 % pendant 30 jours consécutifs, cette situation n'est pas considérée comme une bonne pratique.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Faible utilisation d'un disque ECS

Maintenir l'utilisation des resource des instance ECS à un niveau raisonnable sur la durée constitue un enjeu majeur de la gestion des coûts cloud. La plateforme cloud propose aux entreprises diverses spécifications d'instance ECS. Celles-ci doivent sélectionner les spécifications adaptées en fonction des cycles réels de leur activité afin de maîtriser les coûts. Si l'utilisation d'un disque ECS reste inférieure à 3 % pendant 30 jours consécutifs, cette situation n'est pas considérée comme une bonne pratique.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Faible utilisation des resource d'une instance RDS

Maintenir l'utilisation des resource des instance RDS à un niveau raisonnable sur la durée constitue un enjeu majeur de la gestion des coûts cloud. La plateforme cloud propose aux entreprises diverses spécifications d'instance RDS. Celles-ci doivent sélectionner les spécifications adaptées en fonction des cycles réels de leur activité afin de maîtriser les coûts. Si l'utilisation du CPU, de la mémoire et du disque d'une instance RDS reste inférieure à 3 % pendant 30 jours consécutifs, cette situation n'est pas considérée comme une bonne pratique.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Faible utilisation d'un disque RDS

Maintenir l'utilisation des resource des instance RDS à un niveau raisonnable sur la durée constitue un enjeu majeur de la gestion des coûts cloud. La plateforme cloud propose aux entreprises diverses spécifications d'instance RDS. Celles-ci doivent sélectionner les spécifications adaptées en fonction des cycles réels de leur activité afin de maîtriser les coûts. Si l'utilisation d'un disque RDS reste inférieure à 3 % pendant 30 jours consécutifs, cette situation n'est pas considérée comme une bonne pratique.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Existence d'une instance ALB inactive

Un équilibreur de charge ALB possédant un listener sans serveur backend ajouté et créé il y a plus de 7 jours est considéré comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Existence d'une instance ECS inactive

Une instance ECS à l'état arrêté, pour laquelle le mode sans frais pour instance arrêtée n'est pas configuré, est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Existence d'un disque ECS inactif

Un disque cloud inutilisé et créé il y a plus de 7 jours est considéré comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Existence d'une instance EIP inactive

Une EIP non associée à une instance de resource et créée il y a plus de 7 jours est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Existence d'une instance de système de fichiers NAS inactive

Un système de fichiers NAS sans cible de montage ajoutée et créé il y a plus de 7 jours est considéré comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Existence d'une passerelle NAT inactive

Une passerelle NAT non associée à une EIP, ou dont l'EIP associée ne comporte aucune entrée SNAT/DNAT configurée, et créée il y a plus de 7 jours est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Existence d'une instance SLB inactive

Un équilibreur de charge SLB sans listener actif et créé il y a plus de 7 jours est considéré comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Existence d'une instance de passerelle NAT VPC inactive

Une passerelle NAT VPC non associée à une EIP, ou dont l'EIP associée ne comporte aucune entrée SNAT/DNAT configurée, et créée il y a plus de 7 jours est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Existence d'une passerelle VPN inactive

Une passerelle VPN sans politique de routage basée sur la destination configurée, ou sans propagation automatique des routes BGP activée, et créée il y a plus de 7 jours est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Existence d'une instance de bande passante partagée inactive

Une instance de bande passante partagée non associée à une instance de resource et créée il y a plus de 7 jours est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Optimisation des resource applicatives

Existence d'une instance d'image conteneur inactive

Une instance d'image conteneur sans namespace ni référentiel d'images créé, et créée il y a plus de 7 jours, est considérée comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Politique de coûts

La suite de gestion des coûts n'est pas activée pour le cluster ACK

Les méthodes traditionnelles manquent d'outils efficaces pour la visibilité et le contrôle des coûts dans les scénarios cloud natifs. La suite de gestion des coûts offre des fonctionnalités telles que l'inspection du gaspillage des resource et la prévision des coûts. Si cette suite n'est pas activée pour un cluster ACK, cette configuration n'est pas considérée comme une bonne pratique.

La correction rapide n'est pas prise en charge.

Non

Catégorie

Point de contrôle

Description du point de contrôle

Description de la correction rapide

Prise en charge de l'aide à la décision

Gestion des resource

Les resource associées sont réparties dans différents groupes de ressources

Si les resource associées ne sont pas regroupées dans un groupe de ressources unique, la gestion des permissions, des finances et des opérations basée sur les groupes de ressources ne peut pas couvrir l'ensemble des resource cibles. Un compte est considéré comme non conforme s'il contient des resource associées qui ne font pas partie du même groupe de ressources personnalisé.

La correction rapide n'est pas prise en charge.

Non

Gestion des resource

Absence de tag personnalisés sur les resource

Les tag personnalisés permettent d'identifier, de trier et d'organiser les diverses resource avec plus de flexibilité. Un compte est considéré comme non conforme si la proportion de resource dotées de tag personnalisés par rapport au total des resource est inférieure à 75 %.

La correction rapide n'est pas prise en charge.

Non

Gestion des resource

Absence de regroupement des resource via des groupes de ressources personnalisés

Les groupes de ressources personnalisés offrent une maîtrise plus souple de l'accès et de l'utilisation des resource. Un compte est considéré comme non conforme si la proportion de resource appartenant à des groupes de ressources personnalisés par rapport au total des resource est inférieure à 75 %.

La correction rapide n'est pas prise en charge.

Non

Gestion des resource

Non-utilisation des tag prédéfinis

Les tag prédéfinis sont créés à l'avance et s'appliquent à toutes les régions. Leur utilisation facilite l'association et la gestion des resource cloud lors de la phase de déploiement. Un compte est considéré comme non conforme si la proportion de tag prédéfinis par rapport aux tag personnalisés est inférieure à 80 %.

La correction rapide n'est pas prise en charge.

Non

Gestion des resource

Les tag créateur ne sont pas activés

Avec l'expansion continue du parc de resource cloud, la gestion nécessite l'intervention de plusieurs collaborateurs. Dans des contextes tels que la gestion des coûts ou la sécurité, il est indispensable d'identifier efficacement les créateurs des resource afin de faciliter l'allocation des coûts, la traçabilité de sécurité et d'améliorer l'efficacité globale. Un compte est considéré comme non conforme si les tag créateur ne sont pas activés.

Un tag créateur est un tag système généré et associé automatiquement par Alibaba Cloud à la resource correspondante pour en identifier le créateur. Ces tag facilitent l'analyse des coûts et des factures, permettant ainsi une gestion efficace des dépenses cloud de votre entreprise. Cette correction active les tag créateur pour le compte actuel.

Non

Gestion des resource

Il est recommandé d'activer la fonctionnalité de recherche de resource multi-comptes

Lorsqu'un resource directory est utilisé pour gérer plusieurs comptes Alibaba Cloud, le compte de gestion ou le compte administrateur délégué peut consulter et rechercher les resource cloud de tous les membres du répertoire. Un compte est considéré comme non conforme si la recherche de resource inter-comptes n'est pas activée.

La correction rapide n'est pas prise en charge.

Non

Système de comptes

Le compte n'est pas géré par un resource directory

Comparée à une gestion décentralisée, la gestion unifiée de plusieurs comptes apporte une valeur ajoutée à l'entreprise en matière de permissions, de sécurité et de coûts. Un compte n'appartenant à aucun resource directory est considéré comme non conforme.

La correction rapide n'est pas prise en charge.

Non

Système de comptes

Il est recommandé de centraliser la gestion des contacts de messagerie multi-comptes

La fonctionnalité de gestion des contacts de messagerie du resource directory permet de centraliser les contacts de messagerie sur l'ensemble des comptes. Un compte est considéré comme non conforme si aucun contact de messagerie du resource directory n'est détecté, ou si ce contact n'est pas associé à un resource directory, à un dossier de resources ou à un membre.

La correction rapide n'est pas prise en charge.

Non

Système de comptes

Il est recommandé de définir un compte administrateur délégué pour le resource directory auquel appartient le compte

L'utilisation d'un compte administrateur délégué permet de séparer les tâches de gestion de l'organisation de celles liées à l'activité métier. Le compte de gestion assure les tâches organisationnelles du resource directory, tandis que le compte administrateur délégué exécute les tâches de gestion métier pour les services approuvés. Un compte est considéré comme non conforme si aucun compte administrateur délégué n'est défini parmi les services approuvés activés par le compte de gestion (MA) du resource directory.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API ACK obsolète par l'utilisateur

Les API ACK obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API ACK obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API ALB obsolète par l'utilisateur

Les API ALB obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API ALB obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API CDN obsolète par l'utilisateur

Les API CDN obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API CDN obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API CEN obsolète par l'utilisateur

Les API CEN obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API CEN obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API ECS obsolète par l'utilisateur

Les API ECS obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API ECS obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API NAS obsolète par l'utilisateur

Les API NAS obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API NAS obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API PolarDB obsolète par l'utilisateur

Les API PolarDB obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API PolarDB obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API RDS obsolète par l'utilisateur

Les API RDS obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API RDS obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API Redis obsolète par l'utilisateur

Les API Redis obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API Redis obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API RocketMQ obsolète par l'utilisateur

Les API RocketMQ obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API RocketMQ obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API SLB obsolète par l'utilisateur

Les API SLB obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API SLB obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Appel d'une API VPC obsolète par l'utilisateur

Les API VPC obsolètes ne sont plus maintenues, présentent des risques de stabilité et ne permettent pas d'accéder aux nouvelles fonctionnalités. Un compte est considéré comme non conforme s'il a appelé une API VPC obsolète au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Il est recommandé d'utiliser des méthodes automatisées pour la gestion continue des resource

Un compte est considéré comme non conforme si le ratio d'appels OpenAPI effectués pour gérer les resource de manière continue via des méthodes autres que la console n'a pas atteint 100 % au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Il est recommandé d'utiliser des méthodes automatisées pour l'approvisionnement quotidien des resource

Un compte est considéré comme non conforme si le ratio d'appels OpenAPI effectués pour créer des resource via des méthodes autres que la console n'a pas atteint 100 % au cours de la dernière année.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Il est recommandé d'utiliser des méthodes automatisées pour gérer les resource

Un compte est considéré comme non conforme si le ratio d'appels OpenAPI réalisés via des moyens automatisés tels que SDK, Terraform, Cloud Control API, CADT, ROS et Service Catalog n'a pas atteint 100 % au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Le taux de réussite des appels à l'interface de création de resource n'atteint pas 100 %

Un compte est considéré comme non conforme si le taux de réussite de la création de resource d'infrastructure via des moyens automatisés tels que OpenAPI, Cloud Control API, SDK ou Terraform n'a pas atteint 100 % au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Approvisionnement et orchestration des resource

Le taux de réussite des appels à l'interface de modification de resource n'atteint pas 100 %

Un compte est considéré comme non conforme si le taux de réussite de la modification de resource d'infrastructure via des moyens automatisés tels que OpenAPI, Cloud Control API, SDK ou Terraform n'a pas atteint 100 % au cours des 30 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Catégorie

Point de contrôle

Description du point de contrôle

Description de la correction rapide

Prise en charge de l'aide à la décision

Surveillance des performances

Risque de charge élevée pour l'EIP associée à une instance ALB (Nouveau dans le modèle 3.0)

Une utilisation prolongée et excessive de la bande passante sortante d'une EIP associée à une instance ALB entraîne une dégradation des performances système, une baisse de stabilité, voire des interruptions de service. Il est recommandé de surveiller ce paramètre et d'intervenir rapidement. Une instance ALB est considérée comme non conforme si l'utilisation maximale de la bande passante sortante de l'une de ses EIP associées est supérieure ou égale à 80 % pendant au moins 8 heures au cours des dernières 24 heures.

La correction rapide n'est pas prise en charge.

Non

Surveillance des performances

Risque de charge élevée pour la bande passante partagée associée à une instance ALB (Nouveau dans le modèle 3.0)

Une utilisation prolongée et excessive de la bande passante sortante d'une instance de bande passante partagée associée à une instance ALB entraîne une dégradation des performances système, une baisse de stabilité, voire des interruptions de service. Il est recommandé de surveiller ce paramètre et d'intervenir rapidement. Une instance ALB est considérée comme non conforme si l'utilisation maximale de la bande passante sortante de la bande passante partagée associée est supérieure ou égale à 80 % pendant au moins 8 heures au cours des dernières 24 heures.

La correction rapide n'est pas prise en charge.

Non

Surveillance des performances

Risque de performance pour un disque cloud EBS dû à un débit élevé

Ce contrôle aide les clients à prévenir les goulots d'étranglement, à évaluer l'allocation des resource de stockage et à déterminer si une extension est nécessaire pour garantir la continuité de l'activité. Un disque cloud EBS est considéré comme non conforme si son utilisation IOPS ou BPS au cours des dernières 24 heures dépasse 90 % de la capacité IOPS ou BPS du type de disque concerné.

La correction rapide n'est pas prise en charge.

Non

Surveillance des performances

Risque de performance pour un disque cloud EBS dû à une forte utilisation de l'espace

Une utilisation excessive de l'espace disque accroît le risque de perte de données. Ce contrôle permet aux clients de détecter précocement les goulots d'étranglement potentiels et de prendre des mesures pour éviter toute dégradation des performances. Un disque cloud EBS est considéré comme non conforme si son taux d'utilisation de l'espace dépasse 80 %.

La correction rapide n'est pas prise en charge.

Non

Surveillance des performances

Risque de performance pour une instance ECS dû à une utilisation élevée du CPU

Garantir un niveau sain d'utilisation du CPU pour le produit cloud central ECS est essentiel pour assurer des performances stables et une exploitation continue. Une charge élevée ralentit non seulement les réponses des applications, mais peut également déclencher des mécanismes de protection automatique, tels que le redémarrage automatique du système ou la dégradation du service. Une instance ECS est considérée comme non conforme si son utilisation CPU est excessive, c'est-à-dire supérieure à 85 % pendant un cumul de plus de 8 heures au cours des dernières 24 heures.

La correction rapide n'est pas prise en charge.

Non

Surveillance des performances

Risque de performance pour une instance ECS dû à une utilisation élevée de la mémoire

Il est crucial de maintenir l'utilisation de la mémoire du produit cloud central ECS à un niveau sain afin d'éviter les dégradations de performances ou les interruptions de service causées par un manque de mémoire. Une instance ECS est considérée comme non conforme si son utilisation mémoire est excessive, c'est-à-dire supérieure à 85 % pendant un cumul de plus de 9 heures au cours des dernières 24 heures.

La correction rapide n'est pas prise en charge.

Non

Surveillance des performances

Risque de charge élevée pour une instance RDS (Nouveau dans le modèle 3.0)

Une utilisation prolongée et excessive du CPU, de la mémoire ou du nombre de connexions d'une instance RDS entraîne une dégradation des performances système, une baisse de stabilité, voire des interruptions de service. Il est recommandé de surveiller ces paramètres et d'intervenir rapidement. Une instance RDS est considérée comme non conforme si l'utilisation moyenne du CPU, de la mémoire, du nombre de connexions ou des IOPS est supérieure ou égale à 80 % pendant au moins 8 heures au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Surveillance des performances

Risque de charge élevée pour une instance Redis (Nouveau dans le modèle 3.0)

Une utilisation continue et élevée du CPU ou de la mémoire d'une instance Redis peut entraîner une dégradation des performances système, une baisse de stabilité, voire des interruptions de service. Il est recommandé de surveiller ces paramètres et d'intervenir rapidement. Une instance Redis est considérée comme non conforme si l'utilisation moyenne du CPU ou de la mémoire est supérieure ou égale à 80 % pendant un cumul de plus de 8 heures au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Surveillance des performances

Risque de charge élevée pour une instance SLB (Nouveau dans le modèle 3.0)

Une utilisation prolongée et excessive des connexions maximales, des nouvelles connexions ou du trafic sortant Internet d'une instance SLB entraîne une dégradation des performances système, une baisse de stabilité, voire des interruptions de service. Il est recommandé de surveiller ces paramètres et d'intervenir rapidement. Une instance SLB est considérée comme non conforme si l'utilisation moyenne des connexions maximales, des nouvelles connexions ou du trafic sortant Internet est supérieure ou égale à 80 % pendant au moins 8 heures au cours des 7 derniers jours.

La correction rapide n'est pas prise en charge.

Non

Surveillance des performances

Risque de charge élevée pour une passerelle VPN (Nouveau dans le modèle 3.0)

Une utilisation prolongée et excessive de la bande passante entrante ou sortante d'une passerelle VPN entraîne une dégradation des performances système, une baisse de stabilité, voire des interruptions de service. Il est recommandé de surveiller ces paramètres et d'intervenir rapidement. Une passerelle VPN est considérée comme non conforme si la valeur maximale de son utilisation de bande passante entrante ou sortante est supérieure ou égale à 80 % pendant au moins 8 heures au cours des dernières 24 heures.

La correction rapide n'est pas prise en charge.

Non

Utilisation des resource élastiques

Risque d'incapacité de mise à l'échelle automatique pour le groupe de mise à l'échelle ECS

Les produits cloud centraux tels que les resource ECS peuvent augmenter ou diminuer automatiquement leurs capacity en fonction de la charge, garantissant ainsi un équilibre dynamique durant l'exploitation.

La correction rapide n'est pas prise en charge.

Non

Utilisation des resource élastiques

L'Auto Scaling n'est pas activé pour RDS (Nouveau dans le modèle 3.0)

Si la fonctionnalité Auto Scaling n'est pas activée pour une instance RDS, celle-ci pourrait ne pas être en mesure d'étendre ses resource à temps pour absorber la croissance de la charge pendant les pics d'activité, ou de libérer les resource inactives en période creuse. Cela engendre des goulots d'étranglement, des latences de réponse, voire des interruptions de service, tout en provoquant un gaspillage de resource et des coûts inutiles. L'activation de l'Auto Scaling permet aux clients de bénéficier d'une planification élastique et d'une utilisation efficace des resource, optimisant ainsi la structure des coûts tout en garantissant la stabilité et la haute disponibilité de la base de données, et en améliorant l'intelligence de la gestion des resource cloud. Une instance RDS sans Auto Scaling activé est considérée comme non conforme.

Cette correction active la fonctionnalité d'extension automatique du stockage pour l'instance RDS. Une fois activée, l'espace de stockage s'étend automatiquement dès qu'il atteint le seuil défini. L'extension s'effectue sans redémarrage de l'instance et n'a aucun impact sur l'activité.

Non

Conception réseau

Aucune règle de cache n'est configurée pour un site ESA

Ce point de contrôle vérifie qu'une règle de cache est bien configurée pour le site afin de réduire le trafic vers l'origine. En l'absence de configuration, cette situation n'est pas considérée comme une bonne pratique d'optimisation réseau.

La correction rapide n'est pas prise en charge.

Non

Conception réseau

Le Smart Routing n'est pas activé pour un site ESA dans une région globale

Ce point de contrôle vérifie que le Smart Routing est activé pour le site afin d'améliorer l'effet d'accélération d'ESA dans les régions globales. En l'absence d'activation, cette situation n'est pas considérée comme une bonne pratique d'optimisation réseau.

Cette correction active le Smart Routing pour le site sélectionné. Le Smart Routing utilise les nœuds edge globaux d'Alibaba Cloud pour détecter les conditions réseau en temps réel, sélectionner les routes optimales pour la transmission des données et appliquer des optimisations de pile protocolaire afin de réduire la latence et les échecs de requêtes. Le Smart Routing est facturé au nombre de requêtes (Facturation).

Non

Conception réseau

CDN n'est pas utilisé pour accélérer l'accès aux resource OSS (Nouveau dans le modèle 3.0)

L'utilisation de CDN pour distribuer des resource statiques telles que des images, des vidéos et des documents stockés dans OSS permet de réduire les coûts de trafic et d'améliorer la vitesse de chargement. CDN déploie des nœuds de cache dans plusieurs régions du monde. Lorsqu'un utilisateur demande l'accès à des resource statiques dans OSS, CDN route sa requête vers le nœud de cache le plus proche, évitant ainsi des requêtes longue distance directement vers OSS. Parallèlement, le nœud CDN le plus proche renvoie les resource mises en cache à l'utilisateur sans avoir à les récupérer depuis l'origine OSS. Ce processus génère des coûts de trafic descendant CDN. Comparé au trafic sortant Internet OSS, le prix unitaire du trafic descendant CDN est inférieur. Un bucket OSS est considéré comme non conforme si son trafic entrant sur le réseau public dépasse 100 octets en 24 heures, alors que CDN n'est pas utilisé pour optimiser le transfert des données OSS.

La correction rapide n'est pas prise en charge.

Non

Pilier

Catégorie

Élément de contrôle

Description de l'élément de contrôle

Sécurité

Prévention des abus de privilèges

Trop d'identités RAM disposent de permissions à haut risque pour OSS et SLS

Pour la gestion des permissions des identités RAM, il est recommandé de suivre le principe du moindre privilège en n'accordant que les permissions strictement nécessaires. Une mauvaise gestion des permissions à haut risque peut entraîner une perte de données ou un access non autorisé. Par exemple, des identités RAM dotées de permissions telles que `oss:Delete*` ou `log:Delete*` peuvent supprimer des données stockées dans OSS ou SLS. Celles possédant des permissions comme `oss:PutBucketAcl`, `oss:PutObjectAcl` ou `oss:PutBucketPolicy` peuvent modifier les droits d'access aux fichiers d'un bucket OSS, ce qui risque de les exposer publiquement. Un compte est conforme s'il ne comporte pas plus de trois identités RAM disposant de ces permissions à haut risque.

Sécurité

Prévention des abus de privilèges

Trop d'identités RAM disposent de permissions à haut risque sur le répertoire de resources

Le répertoire de resources permet de gérer de manière centralisée les comptes d'une organisation, d'en créer de nouveaux ou de retirer des comptes existants. Selon les meilleures pratiques, seuls les administrateurs ou les responsables de l'équipe de gestion cloud devraient disposer de permissions d'écriture sur ce répertoire (activation/désactivation, création, invitation ou suppression de comptes, changement de type de compte). En règle générale, une entreprise ne devrait pas compter plus de trois personnes avec ces privilèges. Il est déconseillé d'accorder ces permissions d'écriture à des utilisateurs standards, car des erreurs de manipulation (comme la suppression d'un compte cloud) pourraient impacter gravement l'activité.

Sécurité

Utilisation d'une autorisation granulaire

Existence d'une identité RAM avec un périmètre d'opérations d'access convergent

Concernant la gestion des permissions RAM, appliquez le principe du moindre privilège en n'accordant que les autorisations indispensables. Un compte est conforme si une identité RAM est associée à des permissions opérationnelles spécifiques d'un service cloud.

Sécurité

Utilisation d'une autorisation granulaire

Aucune identité RAM ne dispose d'un access convergent à OSS et SLS

Pour gérer les permissions RAM, respectez le principe du moindre privilège. Pour l'access aux produits de données comme OSS et SLS notamment, privilégiez une autorisation fine afin de limiter les risques de fuite de données liés à la compromission d'une identité. Si une identité RAM possède des permissions sur ces produits, une autorisation granulaire est requise : évitez d'utiliser le caractère générique * pour des autorisations globales. Cette configuration est conforme.

Sécurité

Efficacité et contrôle des autorisations

Le périmètre effectif d'une politique personnalisée attribuée à une identité RAM ne spécifie pas de groupe de ressources

Par défaut, l'attribution d'une politique personnalisée à une identité RAM s'applique au niveau du compte. Sans restriction explicite sur des resources spécifiques ou conditions d'application, l'identité obtient alors les permissions sur toutes les resources du compte. Conformément aux bonnes pratiques de gestion cloud, organisez vos resources par groupes et basez vos autorisations sur ces regroupements. Restreindre le périmètre d'application à un groupe de ressources permet de mieux circonscrire les permissions et d'atteindre une granularité fine. Il est considéré comme une meilleure pratique que le périmètre effectif corresponde à un groupe de ressources ou que celui-ci soit spécifié dans les conditions de la politique.

Sécurité

Efficacité et contrôle des autorisations

Aucune autorisation d'identité RAM avec une politique système de niveau service n'est restreinte à un groupe de ressources

Appliquez le principe du moindre privilège lors de la gestion des permissions RAM. Organiser les resources cloud en groupes selon des critères tels que l'application ou l'environnement facilite l'attribution d'autorisations ciblées, réduisant ainsi le périmètre des permissions et les risques liés aux privilèges excessifs. Un compte est conforme lorsqu'une identité RAM dotée d'une politique système de niveau service (comme AliyunECSFullAccess) voit son périmètre d'autorisation limité à un groupe de ressources.

Sécurité

Efficacité et contrôle des autorisations

Aucune autorisation d'identité RAM avec des permissions Admin n'est restreinte à un groupe de ressources

Respectez le principe du moindre privilège pour la gestion des permissions RAM. Le regroupement des resources cloud par dimensions (application, environnement, etc.) permet d'attribuer des autorisations par groupe, limitant ainsi la portée des permissions et prévenant les risques dus à des droits excessifs. La conformité est atteinte si une identité RAM disposant des permissions AdministratorAccess a un périmètre d'autorisation restreint à un groupe de ressources.

Sécurité

Réponse aux alertes de non-conformité

Aucune règle d'alerte définie pour les événements d'opération à risque

Un compte est non conforme si aucune règle relative à la sécurité du compte ou à la conformité des opérations ActionTrail (prises en charge par les alertes d'événements ActionTrail) n'est activée.

Sécurité

Activation de la correction automatique

Les méthodes automatisées ne sont pas utilisées pour corriger les problèmes de non-conformité

La non-conformité est avérée si l'utilisateur n'a activé la correction automatique pour aucune règle.

Sécurité

Les instances de stockage de données doivent éviter l'access au réseau public

La liste d'autorisation IP de l'instance PolarDB est définie sur 0.0.0.0/0

Une liste d'autorisation IP répertorie les adresses IP autorisées à accéder à un cluster PolarDB. Si elle contient % ou 0.0.0.0/0, toute adresse IP peut se connecter au cluster, ce qui compromet considérablement sa sécurité. Évitez cette configuration sauf nécessité absolue. Les meilleures pratiques recommandent d'appliquer le principe du moindre privilège et de configurer une liste d'autorisation IP appropriée pour garantir un niveau de protection élevé. Définir cette liste sur 0.0.0.0/0 ou % n'est pas conforme aux recommandations.

Sécurité

Les instances de stockage de données doivent éviter l'access au réseau public

La liste d'autorisation IP de l'instance RDS est définie sur 0.0.0.0/0

La liste d'autorisation IP définit les adresses pouvant accéder à une instance RDS. La valeur 0.0.0.0/0 ouvre l'access à toutes les IP, réduisant drastiquement la sécurité de la base de données. N'utilisez ce paramétrage qu'en cas de besoin impératif. Privilégiez le principe du moindre privilège en configurant une liste restrictive pour assurer une protection optimale. Une instance dont la liste d'autorisation IP est fixée à 0.0.0.0/0 ne respecte pas les meilleures pratiques.

Sécurité

Les instances de stockage de données doivent éviter l'access au réseau public

La liste d'autorisation IP de l'instance Redis est définie sur 0.0.0.0/0

Cette liste d'autorisation IP contrôle les connexions entrantes vers une instance Redis. Configurer cette liste sur 0.0.0.0/0 permet à n'importe quelle adresse IP d'accéder à la base de données, ce qui affaiblit considérablement sa sécurité. Sauf exception justifiée, évitez cette configuration. Appliquez le principe du moindre privilège en définissant une liste d'autorisation IP adaptée pour protéger efficacement votre instance. La valeur 0.0.0.0/0 est contraire aux bonnes pratiques.

Sécurité

Les instances de stockage de données doivent éviter l'access au réseau public

La liste d'autorisation IP de l'instance MongoDB est définie sur 0.0.0.0/0

Pour une instance MongoDB, la liste d'autorisation IP recense les adresses autorisées à s'y connecter. La présence de 0.0.0.0/0 signifie un access universel, ce qui représente un risque majeur de sécurité. Ne conservez ce réglage que s'il est strictement indispensable. Conformément au principe du moindre privilège, configurez une liste d'autorisation IP précise pour sécuriser l'instance. Une configuration à 0.0.0.0/0 n'est pas recommandée.

Sécurité

Les instances de stockage de données doivent éviter l'access au réseau public

La liste d'autorisation IP de l'instance Elasticsearch est définie sur 0.0.0.0/0

Les listes d'autorisation IP filtrent les accès aux instances Elasticsearch. Les valeurs 0.0.0.0/0 ou ::/0 autorisent toutes les connexions, exposant l'instance à des risques importants. Évitez cette ouverture totale sauf nécessité absolue. Respectez le principe du moindre privilège en établissant une liste d'autorisation IP restrictive pour garantir un haut niveau de sécurité. Les configurations 0.0.0.0/0 ou ::/0 ne sont pas conformes aux meilleures pratiques.

Stabilité

Protection contre la suppression

La protection contre la libération n'est pas activée pour la resource Redis

Une instance Redis est non conforme si la protection contre la libération n'est pas activée.

Stabilité

Protection contre la suppression

La protection contre la libération n'est pas activée pour la resource ECS

L'absence de protection contre la libération sur une instance ECS entraîne sa non-conformité.

Stabilité

Gestion des changements

La fenêtre de maintenance de la resource Redis est inadaptée

Une instance Redis est considérée comme non conforme si sa plage de sauvegarde automatique ne correspond pas aux créneaux 04:00-05:00, 05:00-06:00 ou 12:00-13:00.

Stabilité

Gestion des changements

La fenêtre de maintenance de la resource PolarDB est inadaptée

Un cluster PolarDB est non conforme lorsque sa fenêtre de maintenance se situe hors des plages 02:00-04:00 ou 06:00-10:00.

Stabilité

Gestion des changements

La fenêtre de maintenance de la resource ADB est inadaptée

Pour être conforme, la fenêtre de maintenance d'un cluster ADB doit tomber dans l'un des créneaux suivants : 02:00-04:00, 06:00-08:00 ou 12:00-13:00.

Stabilité

Gestion des changements

La fenêtre de maintenance de la resource RDS est inadaptée

Une instance RDS dont la fenêtre de maintenance ne se situe pas entre 02:00-06:00 ou 06:00-10:00 est jugée non conforme.

Stabilité

Gestion des changements

La fenêtre de maintenance de la resource ECS est inadaptée

La création d'un snapshot pour une instance ECS réduit temporairement les performances E/S du stockage bloc. Une politique de snapshot automatique est non conforme si l'heure de création n'appartient pas aux créneaux 1 ou 2.

Coût

Optimisation des coûts des resources

Le package de conformité « Meilleures pratiques pour la détection des resources inactives » n'est pas activé

Un compte est non conforme si le package de conformité pour la détection des resources inactives n'est pas activé dans Cloud Config.

Efficacité

Regroupement et isolation des resources

L'utilisation de plusieurs comptes pour gérer les resources d'une même organisation n'est pas effective

Un compte Alibaba Cloud revêt plusieurs significations. Chaque compte constitue un tenant totalement isolé où l'access aux resources, le déploiement réseau et les permissions d'identité sont indépendants par défaut. Associé à une facturation propre, il permet de séparer les services pour une comptabilité distincte. Adopter une gestion multi-comptes favorise l'isolation des environnements, la conformité sécuritaire et l'innovation métier. Cette condition est remplie dès lors qu'une même entité possède au moins deux comptes Alibaba Cloud.

Efficacité

Qualité de l'automatisation

Le quota ECS risque d'être saturé

Des exceptions peuvent survenir lors de la création ou modification de resources, ou de l'utilisation de fonctionnalités produit. Un produit présente un risque s'il affiche un niveau de quota élevé au cours des 7 derniers jours tout ayant rencontré une erreur quota_exceed.

Efficacité

Qualité de l'automatisation

Le quota VPC risque d'être saturé

La création, la modification de resources ou l'usage de fonctionnalités peuvent échouer. Le risque est avéré si un produit présente un quota élevé sur les 7 derniers jours combiné à une erreur quota_exceed.

Efficacité

Qualité de l'automatisation

Le quota SLB risque d'être saturé

Des anomalies sont susceptibles d'affecter la gestion des resources ou l'utilisation des fonctionnalités. Un produit est à risque lorsqu'un quota élevé a été atteint durant la dernière semaine avec une erreur quota_exceed.

Efficacité

Qualité de l'automatisation

Le quota CEN risque d'être saturé

Les opérations sur les resources ou les fonctionnalités produit peuvent rencontrer des erreurs. La saturation est probable si un quota élevé a été enregistré sur 7 jours accompagné d'une erreur quota_exceed.

Efficacité

Qualité de l'automatisation

Le quota ACK risque d'être saturé

Il existe un risque d'exception lors de la manipulation des resources ou fonctionnalités. Ce risque se matérialise quand un produit cumule un quota élevé sur la semaine écoulée et une erreur quota_exceed.

Efficacité

Qualité de l'automatisation

Le quota CDN risque d'être saturé

La gestion des resources ou l'exploitation des fonctionnalités peut être perturbée. Surveillez tout produit affichant un quota élevé ces 7 derniers jours associé à une erreur quota_exceed.