Lista todos os itens de verificação do Modelo de Avaliação de Maturidade de Governança 3.0, incluindo a disponibilidade de correções rápidas e o suporte à decisão assistida.
Segurança
|
Categoria |
Item de Verificação |
Descrição |
Descrição da Correção Rápida |
Suporte à Decisão Assistida |
|
Gestão de identidade de pessoal |
A autenticação multifator (MFA) não está ativada para a conta Alibaba Cloud |
Ative a autenticação multifator (MFA) na sua conta Alibaba Cloud para adicionar uma camada extra de segurança. Configurações sem MFA são consideradas não conformes. |
Não suportado. |
Não |
|
Gestão de identidade de pessoal |
Um usuário do Resource Access Management (RAM) possui login no console e AccessKey ativos simultaneamente |
Pelo princípio do menor privilégio, um usuário RAM não deve ter login no console e AccessKey habilitados ao mesmo tempo. Essa condição torna a configuração não conforme. Se o single sign-on (SSO) estiver ativado na conta, a configuração de login no console é ignorada. Contudo, a configuração ainda será considerada não conforme se o usuário tiver um AccessKey e tiver feito login no console nos últimos 7 dias. |
Esta correção desativa o login no console para o usuário RAM selecionado. Antes de aplicar a correção, confirme que o usuário não precisa mais acessar o console. |
Sim |
|
Gestão de identidade de pessoal |
Um usuário RAM não tem MFA ativado |
O MFA fornece uma camada adicional de segurança para usuários RAM. Se um usuário RAM tiver login no console habilitado, mas não tiver MFA ativado, a configuração é não conforme. |
Não suportado. |
Sim |
|
Gestão de identidade de pessoal |
O RAM não é utilizado para gestão de identidades |
A conta Alibaba Cloud possui permissões amplas, e um comprometimento representaria um alto risco de segurança. Utilize identidades RAM para operações diárias. Se não existirem identidades RAM, a configuração é não conforme. |
Não suportado. |
Não |
|
Gestão de identidade de pessoal |
Um usuário RAM não atende aos requisitos de força de senha |
Aplicar políticas de senha fortes reduz o risco de ataques de credential stuffing e força bruta. A configuração é não conforme se os requisitos de comprimento, tipos de caracteres, expiração, histórico ou limites de tentativas não forem aplicados. |
Esta correção atualiza as configurações de força de senha no RAM. As definições são: comprimento mínimo de 8 caracteres, exigência de pelo menos três tipos de caracteres, idade máxima da senha de 90 dias e limite de cinco tentativas de login por hora. Estas são recomendações de melhores práticas. Ajuste os parâmetros para impor requisitos mais rigorosos. Após a conclusão, as configurações se aplicam a todos os usuários RAM. |
Não |
|
Gestão de identidade de pessoal |
A conta Alibaba Cloud fez login no console nos últimos 90 dias |
A conta Alibaba Cloud tem permissões extensas que não podem ser restringidas por condições como IP de origem ou horário. O comprometimento desta conta representa um alto risco de segurança. Se a conta foi usada para fazer login no console nos últimos 90 dias, a configuração é não conforme. |
Não suportado. |
Não |
|
Gestão de identidade de pessoal |
Existe um usuário RAM inativo |
Usuários RAM com login no console habilitado usam senhas para autenticação. Quanto mais tempo uma senha existir, maior o risco de exposição. Se um usuário RAM não fizer login por mais de 90 dias, a configuração é não conforme. |
Esta correção desativa o login no console para o usuário RAM selecionado. Antes de aplicar a correção, confirme que o usuário não precisa mais acessar o console. Observação: Se o SSO estiver ativado, desativar o login no console não remove o usuário da lista de recursos. Para limpar o alerta, exclua o usuário RAM. |
Sim |
|
Gestão de identidade de pessoal |
O SSO do RAM não está habilitado para login no console |
Use o SSO para gerenciar identidades de usuários centralizadamente e reduzir riscos de segurança. A configuração é não conforme se o SSO do RAM não estiver configurado ou se nenhum login via SSO tiver ocorrido nos últimos 30 dias. |
Não suportado. |
Não |
|
Gestão de identidade de pessoal |
Recomenda-se a gestão unificada para identidades de múltiplas contas |
Utilize o Cloud SSO para gerenciar todos os usuários da sua organização. Configure seu provedor de identidade empresarial (IdP) para o Alibaba Cloud SSO e defina permissões de acesso uniformes para contas membro no seu Resource Directory (RD). Se o Cloud SSO não for usado por mais de 90 dias, a configuração é não conforme. |
Não suportado. |
Não |
|
Gestão de identidade de pessoal |
A sincronização de usuários SCIM do RAM não está ativada |
O System for Cross-domain Identity Management (SCIM) sincroniza identidades empresariais com a Alibaba Cloud, eliminando a necessidade de criação manual de usuários. A configuração é não conforme se o SCIM não estiver configurado ou se os usuários sincronizados não tiverem feito login por dois meses. |
Não suportado. |
Não |
|
Gestão de identidade programática |
Existe um AccessKey ativo para a conta Alibaba Cloud |
Um AccessKey de uma conta Alibaba Cloud concede permissões totais à conta. Ele não pode ser restringido por condições como IP de origem ou horário. O vazamento deste AccessKey representa um alto risco de segurança. Se existir um AccessKey ativo para a conta, a configuração é não conforme. |
Esta correção desativa o AccessKey selecionado da conta Alibaba Cloud. Antes de aplicar a correção, confirme que o AccessKey não é usado por nenhum programa ou aplicação. Desativar o AccessKey melhora parcialmente a pontuação de segurança, mas o alerta persiste até que o AccessKey seja excluído. Observação: Apenas a conta Alibaba Cloud pode executar esta correção. Tentativas realizadas por um usuário RAM ou função RAM falharão. |
Sim |
|
Gestão de identidade programática |
Um usuário RAM possui dois AccessKeys ativos |
Um usuário RAM com dois AccessKeys ativos não consegue realizar o rodízio adequado, o que aumenta os riscos de segurança. Se um usuário RAM tiver dois AccessKeys ativos, a configuração é não conforme. |
Esta correção desativa o AccessKey selecionado do usuário RAM. Antes de aplicar a correção, confirme que o AccessKey não é usado por nenhum programa ou aplicação. |
Sim |
|
Gestão de identidade programática |
Existe um AccessKey exposto e não tratado |
Se um AccessKey for exposto, atacantes poderão usá-lo para acessar seus recursos e dados. Se houver um evento de exposição de AccessKey não tratado, a configuração é não conforme. |
Não suportado. |
Não |
|
Gestão de identidade programática |
Uma chave KMS está agendada para exclusão (novo no modelo 3.0) |
Quando uma chave mestra do cliente (CMK) é excluída, ela não pode ser recuperada. Dados criptografados com a CMK e suas chaves de dados associadas tornam-se permanentemente indecifráveis. Para evitar exclusões acidentais e interrupções de serviço, garanta que CMKs ativas não estejam agendadas para exclusão. Se uma CMK estiver agendada para exclusão, a configuração é não conforme. |
Esta correção cancela a exclusão agendada da chave KMS selecionada. O status da chave muda de Agendada para Exclusão para Ativada. Após a ativação, a chave pode ser usada para criptografar e descriptografar dados, e as cobranças padrão se aplicam. |
Não |
|
Gestão de identidade programática |
Um AccessKey não passou por rodízio regular |
Realizar o rodízio regular de AccessKeys reduz o tempo de exposição e diminui o risco de vazamentos. Se o AccessKey de um usuário RAM estiver em uso por mais de 365 dias, a configuração é não conforme. |
Não suportado. |
Não |
|
Gestão de identidade programática |
Existe um AccessKey inativo |
O AccessKey de um usuário RAM permite acesso via API à Alibaba Cloud. Quanto mais tempo um AccessKey ficar exposto, maior o risco de vazamento. Se um AccessKey não for usado por mais de 365 dias, a configuração é não conforme. |
Esta correção desativa o AccessKey selecionado do usuário RAM. Antes de aplicar a correção, confirme que o AccessKey não é usado por nenhum programa ou aplicação. Desativar o AccessKey melhora parcialmente a pontuação de segurança, mas o alerta persiste até que o AccessKey seja excluído. |
Sim |
|
Gestão de identidade programática |
Uma instância Redis não tem autenticação por senha ativada (novo no modelo 3.0) |
Se uma instância Redis em uma VPC não tiver autenticação por senha ativada ou possuir configurações de segurança incorretas, isso pode levar a vazamentos de dados, ações maliciosas não autorizadas, problemas de segurança de rede ou interrupções de serviço. Se a autenticação por senha estiver desativada para uma instância Redis em uma VPC, a configuração é não conforme. |
Não suportado. |
Não |
|
Gestão de identidade programática |
O acesso programático não utiliza uma solução sem AccessKey |
A configuração é não conforme se instâncias ECS não tiverem funções de instância, clusters ACK não tiverem o plug-in RRSA ativado ou serviços Function Compute não tiverem funções de serviço. |
Não suportado. |
Não |
|
Gestão de identidade programática |
Uma instância ECS não usa o Metadata Service reforçado (V2) |
Utilize o Metadata Service reforçado (V2) para instâncias ECS a fim de evitar possíveis vazamentos de tokens do Security Token Service (STS) que podem ocorrer na versão V1. Se uma instância ECS usar a V1, a configuração é não conforme. Para resolver esse problema, atualize o Metadata Service para a V2. |
Não suportado. |
Não |
|
Gestão de permissões |
Muitas identidades RAM possuem a permissão AdministratorAccess |
De acordo com o princípio do menor privilégio, limite o número de identidades RAM com a permissão AdministratorAccess. Essa permissão permite controle total sobre todos os recursos, e concedê-la a muitas identidades aumenta o impacto de um possível vazamento de credenciais. A configuração é conforme se três ou menos identidades RAM possuírem a permissão AdministratorAccess. |
Esta correção substitui a permissão AdministratorAccess pela PowerUserAccess. A PowerUserAccess concede acesso total aos serviços e recursos da Alibaba Cloud, mas não inclui permissões para gerenciar identidades RAM, Resource Directory, recursos compartilhados ou informações financeiras da conta. A correção analisa logs de auditoria de permissões e substitui automaticamente a permissão AdministratorAccess pela PowerUserAccess para identidades de administrador não utilizadas. |
Não |
|
Gestão de permissões |
Muitas identidades RAM não administradoras possuem permissões de faturamento de alto risco |
Seguindo o princípio do menor privilégio, limite as permissões de faturamento de alto risco. Permissões como |
Não suportado. |
Não |
|
Gestão de permissões |
Muitas identidades RAM não administradoras possuem permissões de alto privilégio |
Em conformidade com o princípio do menor privilégio, restrinja permissões de alto privilégio. Essas permissões permitem que identidades RAM escalem suas próprias permissões ou as de outros. O uso indevido pode comprometer a segurança e a confidencialidade dos seus recursos. A configuração é conforme se três ou menos identidades RAM não administradoras possuírem permissões de alto privilégio. Uma lista completa está disponível em na documentação. |
Não suportado. |
Não |
|
Gestão de permissões |
Uma identidade RAM não administradora tem permissões de descriptografia para todas as chaves KMS |
O KMS permite controlar quem pode usar suas chaves e acessar dados criptografados. Políticas RAM definem as ações que identidades (usuários, grupos ou funções) podem executar em recursos específicos. Siga as melhores práticas de segurança concedendo apenas as permissões necessárias e restringindo o acesso a chaves específicas. Conceder a permissão |
Não suportado. |
Não |
|
Gestão de permissões |
Uma identidade RAM possui permissões ociosas no nível de produto |
Permissões no nível de produto são consideradas ociosas se não forem usadas por um período especificado após a concessão. Isso pode ocorrer devido a mudanças de função ou se as permissões iniciais forem muito amplas. Como melhor prática, revogue permissões ociosas para alcançar uma autorização refinada. Se uma identidade RAM tiver permissões ociosas no nível de produto por 180 dias, a configuração não estará em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Gestão de permissões |
Uma identidade RAM possui permissões ociosas para operações de alto risco |
Permissões para operações de alto risco, como criar usuários RAM, são consideradas ociosas se não forem usadas por um período especificado após a concessão. Isso pode ocorrer devido a mudanças de função ou se as permissões iniciais forem muito amplas. Revogue prontamente permissões ociosas de alto risco para prevenir incidentes de segurança. Se uma identidade RAM tiver permissões ociosas para operações de alto risco por 180 dias, a configuração não estará em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Gestão de permissões |
Todas as identidades RAM possuem a permissão AdministratorAccess |
Para limitar o impacto de um possível vazamento de identidade, evite conceder a permissão AdministratorAccess a todas as identidades RAM, seguindo o princípio do menor privilégio. A configuração é conforme se pelo menos uma identidade RAM tiver permissões não administradoras. |
Esta correção substitui a permissão AdministratorAccess pela PowerUserAccess. A PowerUserAccess concede acesso total aos serviços e recursos da Alibaba Cloud, mas não inclui permissões para gerenciar identidades RAM, Resource Directory, recursos compartilhados ou informações financeiras da conta. A correção analisa logs de auditoria de permissões e substitui automaticamente a permissão AdministratorAccess pela PowerUserAccess para identidades de administrador não utilizadas. |
Não |
|
Gestão de permissões |
O Access Analyzer não é usado para gestão de permissões (novo no modelo 3.0) |
O Access Analyzer ajuda a identificar recursos compartilhados com contas externas e detecta compartilhamentos inesperados para reduzir riscos de segurança. Ele também identifica identidades com permissões excessivas e gera relatórios de análise. |
Não suportado. |
Não |
|
Gestão de permissões |
Recomenda-se o uso de políticas de controle para proteção de limites em ambientes de múltiplas contas |
As políticas de controle do Resource Directory permitem que organizações restrinjam os serviços de nuvem e operações que as contas membro podem acessar. Isso ajuda a centralizar a gestão de limites de permissão e garante conformidade com padrões de segurança. A configuração é não conforme se nenhuma política de controle personalizada for criada e anexada a uma pasta do Resource Directory ou conta membro. |
Não suportado. |
Não |
|
Gestão de permissões |
Nenhum usuário RAM herda permissões de um grupo de usuários RAM |
Por padrão, usuários, grupos e funções RAM não podem acessar nenhum recurso. Você deve conceder permissões usando políticas RAM. Para simplificar a gestão e reduzir o risco de expansão acidental de permissões, aplique políticas a grupos ou funções em vez de usuários individuais. A configuração está em conformidade com as melhores práticas se pelo menos um usuário RAM herdar permissões de um grupo de usuários RAM. |
Não suportado. |
Não |
|
Coleta e arquivamento de logs |
Logs do ActionTrail não são retidos a longo prazo |
A configuração é não conforme se nenhum trail for criado, ou se um trail existente não arquivar eventos de todas as regiões, não arquivar todas as operações de leitura e gravação, ou reter logs por menos de 180 dias. |
Esta correção aprimora as configurações de um trail existente para incluir todos os eventos de leitura e gravação de gerenciamento e eventos de todas as regiões. Selecione pelo menos um trail existente para atualizar. Novos eventos gerados após a aplicação da correção são entregues ao armazenamento de destino do trail. Eventos históricos não são afetados. |
Não |
|
Coleta e arquivamento de logs |
O EDAS não tem coleta de logs configurada (novo no modelo 3.0) |
O Alibaba Cloud Enterprise Distributed Application Service (EDAS) integra-se ao Simple Log Service (SLS) para coletar logs de aplicações e logs stdout de contêineres de clusters Kubernetes para consulta e análise. Se a coleta de logs não estiver configurada para o EDAS, a configuração é não conforme. |
Não suportado. |
Não |
|
Coleta e arquivamento de logs |
Um bucket OSS não tem consulta de logs em tempo real ativada (novo no modelo 3.0) |
O recurso de log em tempo real do OSS registra acessos aos buckets para fins de auditoria, monitoramento e análise. A configuração é não conforme se o log em tempo real estiver desativado ou se o período de retenção de logs for de 180 dias ou menos. |
Não suportado. |
Não |
|
Coleta e arquivamento de logs |
Um bucket OSS não tem entrega de logs ativada (novo no modelo 3.0) |
Logs de acesso do OSS podem gerar um grande volume de dados. O recurso de entrega de logs grava arquivos de log horários em um bucket especificado usando uma convenção de nomenclatura fixa. Analise os logs entregues usando Simple Log Service ou clusters Spark. A configuração é conforme se a entrega de logs estiver ativada para um bucket OSS. |
Não suportado. |
Não |
|
Coleta e arquivamento de logs |
Um site ESA não tem tarefa de entrega de logs configurada |
Esta verificação confirma se pelo menos um tipo de log está configurado para o site, fornecendo logs de acesso em tempo real para monitoramento, análise e otimização de entrega de conteúdo. Se nenhum tipo de log estiver configurado, a configuração não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Coleta e arquivamento de logs |
Logs do Cloud Firewall não são coletados e armazenados por 180 dias ou mais |
O Cloud Firewall registra automaticamente todo o tráfego e fornece páginas de auditoria visualizadas para eventos de ataque, detalhes de tráfego e logs de operação. O período padrão de retenção de logs é de 7 dias. Para conformidade e segurança aprimorada, armazene logs por 180 dias ou mais. Se você adquiriu uma edição por assinatura do Cloud Firewall, mas não armazena logs por 180 dias ou mais, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Esta correção ativa a análise de logs para o Cloud Firewall e define o período de retenção. Para cumprir regulamentações de proteção de dados e segurança de rede, o período de retenção deve ser de 180 dias ou mais. Após ativar este recurso, o Cloud Firewall cria um Project e Logstore dedicados para armazenar todos os logs. Taxas são aplicadas com base na duração da retenção e capacidade de armazenamento. Detalhes de faturamento. |
Não |
|
Coleta e arquivamento de logs |
Recomenda-se a agregação centralizada de logs de operação de múltiplas contas |
O ActionTrail armazena eventos por 90 dias por padrão. Criar trails ajuda a persistir registros de operação para fins de conformidade. Trails de múltiplas contas permitem que administradores rastreiem e auditem logs centralizadamente em várias contas. Se não existir nenhum trail de múltiplas contas, a configuração é não conforme. |
Não suportado. |
Não |
|
Coleta e arquivamento de logs |
Recomenda-se ativar a coleta centralizada de logs para ambientes de múltiplas contas |
Se o serviço confiável para auditoria de logs do Simple Log Service (SLS) estiver desativado, a configuração é não conforme. |
Não suportado. |
Não |
|
Verificações de conformidade |
Recursos de nuvem estão não conformes |
Se as regras do Cloud Config detectarem não conformidade e a taxa de recursos conformes for inferior a 100%, a configuração é não conforme. |
Não suportado. |
Não |
|
Verificações de conformidade |
O Cloud Config não está ativado |
Se o Cloud Config não estiver ativado, a configuração é não conforme. |
Não suportado. |
Não |
|
Verificações de conformidade |
Regras de conformidade do Cloud Config não estão ativadas |
Se as regras de conformidade do Cloud Config não estiverem ativadas, a configuração é não conforme. |
Não suportado. |
Não |
|
Verificações de conformidade |
Regras de conformidade do Cloud Config não cobrem todos os recursos de nuvem |
Se a cobertura de regras for inferior a 100%, a configuração é não conforme. |
Não suportado. |
Não |
|
Verificações de conformidade |
Recomenda-se ativar verificações de configuração unificadas para ambientes de múltiplas contas |
A configuração é não conforme se qualquer uma das seguintes condições não for atendida: 1. Existe um grupo de contas com regras configuradas. 2. Eventos de não conformidade são entregues ao SLS. |
Não suportado. |
Não |
|
Verificações de conformidade |
Dados de verificação de conformidade não são recuperados regularmente |
Se o Cloud Config não entregar eventos de não conformidade ou se os resultados não forem visualizados nos últimos 7 dias, a configuração é não conforme. |
Esta correção cria uma tarefa de entrega de dados de recursos na conta atual. Ela entrega snapshots de configuração e conformidade, além de alterações, para SLS, OSS ou MNS em uma conta Alibaba Cloud especificada para persistência e notificações. Tarefas de entrega são gratuitas, mas cobranças padrão de entrega de dados se aplicam. Detalhes de faturamento. |
Não |
|
Verificações de conformidade |
Entrega de alterações de recursos ou snapshots não está configurada |
Se o Cloud Config não entregar alterações de recursos ou snapshots, a configuração é não conforme. |
Esta correção cria uma tarefa de entrega de dados de recursos na conta atual. Ela entrega snapshots de configuração e conformidade, além de alterações, para SLS, OSS ou MNS em uma conta Alibaba Cloud especificada para persistência e notificações. Tarefas de entrega são gratuitas, mas cobranças padrão de entrega de dados se aplicam. Detalhes de faturamento. |
Não |
|
Proteção de recursos de computação |
Problemas de linha de base de host requerem correção |
Vírus e hackers exploram fraquezas na configuração de servidores para roubar dados ou instalar backdoors. Verificações de linha de base avaliam configurações de SO, banco de dados, software e contêineres. Corrigir problemas de linha de base fortalece a segurança, reduz riscos de intrusão e ajuda a atender requisitos de conformidade. Se existirem linhas de base não corrigidas, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de recursos de computação |
Vulnerabilidades requerem correção |
A gestão de vulnerabilidades é um processo contínuo e proativo. Ela protege sistemas, redes e aplicações contra ciberataques e violações de dados. A correção oportuna previne ataques e minimiza danos. Se existirem vulnerabilidades não corrigidas, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de recursos de computação |
A proteção contra ransomware não está ativada |
Ransomware criptografa dados comerciais, o que pode causar interrupções de serviço, vazamentos de dados e perda de dados. Configurar proteção contra ransomware reduz esses riscos. Se a proteção contra ransomware for adquirida, mas nenhuma política de proteção for criada, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de recursos de computação |
O antivírus não está ativado |
Varreduras antivírus limpam ameaças maliciosas, incluindo ransomware, trojans DDoS, malware de mineração, backdoors e worms. Se o antivírus for adquirido para o Security Center (Edição Enterprise ou Ultimate), mas nenhuma política de varredura periódica for configurada, a configuração é não conforme. |
Esta correção configura a varredura periódica de vírus no Security Center. Após a aplicação da correção, a varredura é executada em todos os servidores elegíveis de acordo com o intervalo e a janela de tempo configurados. Alertas de vírus aparecem no módulo de alertas de segurança. Trate-os prontamente para garantir a segurança do servidor. |
Não |
|
Proteção de recursos de computação |
A varredura de imagens de contêiner não está configurada |
Imagens com vulnerabilidades de sistema ou aplicação, ou imagens substituídas por versões maliciosas, podem introduzir riscos. Varrer imagens em registradores ajuda equipes de segurança a enviar descobertas para desenvolvedores para correção. Se a varredura de imagens for adquirida, mas nenhum escopo de varredura for configurado, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de runtime de aplicação |
Um site ESA não tem regras gerenciadas WAF configuradas |
Esta verificação confirma se os sites possuem regras gerenciadas WAF para proteger melhor aplicações web e API. Se nenhuma regra gerenciada estiver configurada, a configuração não está em conformidade com as melhores práticas de Proteção de Aplicações Web. |
Regras gerenciadas são regras inteligentes integradas para ESA. Elas protegem contra ataques OWASP e vulnerabilidades emergentes de origem. Esta correção ativa o conjunto de regras gerenciadas para o site ESA selecionado. A disponibilidade de regras varia por edição (recursos suportados por edição). |
Não |
|
Proteção de runtime de aplicação |
Um site ESA não tem regras personalizadas WAF configuradas |
Esta verificação confirma se os sites possuem regras personalizadas WAF para detectar e mitigar solicitações maliciosas. Se nenhuma regra personalizada estiver configurada, a configuração não está em conformidade com as melhores práticas de Proteção de Aplicações Web. |
Não suportado. |
Não |
|
Proteção de runtime de aplicação |
Configurações de proteção de aplicação não foram criadas |
A detecção e proteção em runtime defendem aplicações Java contra vulnerabilidades de dia zero. Se a proteção de aplicação for adquirida, mas não existirem configurações ou grupos, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de runtime de aplicação |
A Proteção Contra Adulteração Web não está ativada |
A Proteção Contra Adulteração Web monitora diretórios ou arquivos de sites em tempo real e restaura conteúdos adulterados a partir de backups. Ela previne injeção de conteúdo ilegal e garante a disponibilidade do site. Se a Proteção Contra Adulteração Web for adquirida, mas nenhum servidor estiver vinculado, a configuração é não conforme. |
Não suportado. |
Não |
|
Resposta a ataques de rede |
Anti-DDoS Pro ou Anti-DDoS Premium excede limites de defesa (novo no modelo 3.0) |
Se o tráfego de ataque exceder a largura de banda de proteção de uma instância Anti-DDoS, a instância entra em modo black hole. Todo o tráfego roteado através dela é bloqueado, tornando os serviços inacessíveis. Se o status IP da instância Anti-DDoS for Black Hole Ativado, a configuração é não conforme. |
Não suportado. |
Não |
|
Resposta a ataques de rede |
Uma instância ECS excede limites de defesa DDoS (novo no modelo 3.0) |
Se uma instância ECS sofrer ataques DDoS de alto volume que excedam sua largura de banda de defesa, a política de black hole da Alibaba Cloud bloqueia o tráfego entre a instância e a Internet para evitar danos maiores e proteger outros ativos. Se uma instância ECS com Endereço IP Público Aberto tiver status de proteção DDoS como Black Hole Ativado, a configuração é não conforme. |
Não suportado. |
Não |
|
Resposta a ataques de rede |
Um EIP excede limites de defesa DDoS (novo no modelo 3.0) |
Se um EIP sofrer ataques DDoS de alto volume que excedam sua largura de banda de defesa, a política de black hole da Alibaba Cloud bloqueia o tráfego entre o EIP e a Internet para evitar danos maiores e proteger outros ativos. Se o status de proteção DDoS de um EIP for Black Hole Ativado, a configuração é não conforme. |
Não suportado. |
Não |
|
Resposta a ataques de rede |
Uma instância SLB excede limites de defesa DDoS (novo no modelo 3.0) |
Se uma instância SLB sofrer ataques DDoS de alto volume que excedam sua largura de banda de defesa, a política de black hole da Alibaba Cloud bloqueia o tráfego entre a instância e a Internet para evitar danos maiores e proteger outros ativos. Se o status de proteção DDoS de uma instância SLB for Black Hole Ativado, a configuração é não conforme. |
Não suportado. |
Não |
|
Resposta a ataques de rede |
A proteção DDoS nativa não tem objetos protegidos adicionados |
Após adquirir Proteção DDoS Nativa ou instâncias Anti-DDoS, adicione ativos de IP público como objetos protegidos para ativar a proteção DDoS. Sem essa etapa, a proteção é ineficaz e os custos são desperdiçados. |
Não suportado. |
Não |
|
Resposta a ataques de rede |
A proteção inteligente baseada em IA para sites está definida como modo Rigoroso |
A proteção inteligente baseada em IA melhora a segurança do site. No entanto, o modo Rigoroso pode causar falsos positivos. Use o modo Rigoroso apenas para sites com baixo desempenho ou proteção inadequada. Observação: Domínios de sites possuem proteção integrada contra ataques de Camada 4. Para a maioria dos sites, use o modo Normal para equilibrar proteção e continuidade dos negócios. |
Esta correção define a proteção inteligente baseada em IA como Modo de Bloqueio com severidade Normal. O Anti-DDoS Proxy gerará automaticamente regras precisas de controle de acesso e defenderá inteligentemente contra ataques maliciosos quando ameaças forem detectadas. |
Não |
|
Controle de acesso à rede |
Uma instância ECS não está proibida de ser vinculada a um endereço IP público |
Para reduzir o risco de ataques, evite expor instâncias ECS diretamente à Internet pública. Use NAT Gateway ou Server Load Balancer. Se uma instância ECS estiver vinculada a um endereço IP público, a configuração é não conforme. |
Não suportado. |
Não |
|
Controle de acesso à rede |
Uma instância Elasticsearch tem endpoint público ativado e nenhuma lista de permissões de endereços IP |
Expor o Elasticsearch à Internet pública representa riscos de segurança. Ele torna-se visível para atacantes e pode sofrer vazamentos ou destruição de dados sem controles de acesso adequados. Como melhor prática, permita acesso apenas de redes internas VPC e configure listas de permissões IP apropriadas. Se um endpoint público estiver ativado, a configuração não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Controle de acesso à rede |
O serviço Kibana de uma instância Elasticsearch tem endpoint público ativado e nenhuma lista de permissões de endereços IP |
Expor o Kibana à Internet pública representa riscos de segurança. Ele torna-se visível para atacantes e pode sofrer vazamentos ou destruição de dados sem controles de acesso adequados. Como melhor prática, permita acesso apenas de redes internas VPC e configure listas de permissões IP apropriadas. Se o endpoint público do Kibana estiver ativado, a configuração não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Controle de acesso à rede |
Uma instância MongoDB tem endpoint público ativado e nenhuma lista de permissões de endereços IP |
Expor bancos de dados à Internet pública representa riscos de segurança. Eles tornam-se visíveis para atacantes e podem sofrer vazamentos ou destruição de dados sem controles de acesso adequados. Como melhor prática, permita acesso apenas de redes internas VPC, configure listas de permissões IP e use credenciais fortes. Se um endpoint público estiver ativado, a configuração é não conforme. |
Não suportado. |
Não |
|
Controle de acesso à rede |
Um cluster PolarDB tem endpoint público configurado |
Expor bancos de dados à Internet pública representa riscos de segurança. Eles tornam-se visíveis para atacantes e podem sofrer vazamentos ou destruição de dados sem controles de acesso adequados. Como melhor prática, permita acesso apenas de redes internas VPC, configure listas de permissões IP e use credenciais fortes. Se um endpoint público estiver ativado, a configuração não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Controle de acesso à rede |
Uma instância RDS tem endpoint público ativado e nenhuma lista de permissões de endereços IP |
Expor bancos de dados à Internet pública representa riscos de segurança. Eles tornam-se visíveis para atacantes e podem sofrer vazamentos ou destruição de dados sem controles de acesso adequados. Como melhor prática, permita acesso apenas de redes internas VPC, configure listas de permissões IP e use credenciais fortes. Se um endpoint público estiver ativado, a configuração não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Controle de acesso à rede |
Uma instância Redis tem endpoint público configurado |
Expor bancos de dados à Internet pública representa riscos de segurança. Eles tornam-se visíveis para atacantes e podem sofrer vazamentos ou destruição de dados sem controles de acesso adequados. Como melhor prática, permita acesso apenas de redes internas VPC, configure listas de permissões IP e use credenciais fortes. Se um endpoint público estiver ativado, a configuração não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Controle de acesso à rede |
Uma regra de entrada de grupo de segurança permite acesso de 0.0.0.0/0 a qualquer porta |
Não permita que todos os endereços IP (0.0.0.0/0) acessem qualquer porta. Restrinja o acesso a intervalos de IP e portas específicos. Se uma regra de entrada de grupo de segurança permitir acesso de 0.0.0.0/0 sem especificar portas, a configuração é não conforme. |
Não suportado. |
Não |
|
Controle de acesso à rede |
Uma instância Tablestore tem acesso por rede pública e clássica ativado |
O Tablestore cria um nome de domínio público, um nome de domínio VPC e um nome de domínio de rede clássica para cada instância. Nomes de domínio públicos são acessíveis pela Internet. Nomes de domínio de rede clássica são acessíveis por instâncias ECS na mesma região. Como melhor prática, permita acesso apenas pelo console ou por uma VPC. Restringir o acesso por rede pública e clássica melhora o isolamento de rede e a segurança dos dados. Se o tipo de rede estiver definido como "Apenas Console ou VPC" ou "Apenas VPC", a configuração está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Controle de acesso à rede |
O servidor de API de um cluster ACK tem endpoint público ativado (novo no modelo 3.0) |
Ativar um endpoint público para um cluster ACK aumenta o risco de ataques a recursos como pods, serviços e controladores de réplica. Não ative endpoints públicos. Se um endpoint público estiver ativado, a configuração é não conforme. |
Não suportado. |
Não |
|
Controle de acesso à rede |
O tipo de rede de um modelo de inicialização ECS está definido como rede clássica (novo no modelo 3.0) |
A rede clássica não oferece isolamento no nível de rede entre usuários. Múltiplos locatários compartilham o mesmo pool de IPs, e usuários não podem personalizar topologias de rede ou endereços IP. Vulnerabilidades em aplicações de rede clássica podem expô-las a outros locatários. A Virtual Private Cloud (VPC) fornece segurança mais forte. Para organizações que priorizam segurança de dados, a VPC é a melhor escolha. Se um modelo de inicialização ECS usar a rede clássica, a configuração é não conforme. |
Não suportado. |
Não |
|
Controle de acesso à rede |
O nó mestre de um cluster EMR tem endpoint público ativado (novo no modelo 3.0) |
Atribuir um endereço IP público a um nó mestre EMR aumenta sua exposição a ataques. Atacantes podem escanear, infiltrar ou realizar outras ações maliciosas, ameaçando todo o cluster. Se um endpoint público estiver ativado, a configuração é não conforme. |
Não suportado. |
Não |
|
Controle de acesso à rede |
Uma regra de entrada de grupo de segurança associada a um grupo de dimensionamento ESS permite acesso de 0.0.0.0/0 a qualquer porta (novo no modelo 3.0) |
Quando atividades de dimensionamento são acionadas, o Auto Scaling cria instâncias ECS usando a configuração de dimensionamento. Se a regra de entrada do grupo de segurança associado permitir todos os endereços IP (0.0.0.0/0) em qualquer porta, as novas instâncias enfrentarão riscos de segurança. Se tal regra existir, a configuração é não conforme. |
Não suportado. |
Não |
|
Controle de acesso à rede |
Um projeto MaxCompute não tem lista de permissões de endereços IP (novo no modelo 3.0) |
Com uma lista de permissões de endereços IP, apenas dispositivos listados podem acessar o projeto. Sem uma lista de permissões, qualquer dispositivo que use um endpoint público pode acessar o projeto, o que representa riscos de exposição. Se o projeto permitir acesso à rede externa sem uma lista de permissões de endereços IP, a configuração é não conforme. |
Não suportado. |
Não |
|
Controle de acesso à rede |
Um grupo de segurança expõe portas de alto risco (22, 3389, etc.) à Internet pública |
Não permita acesso da Internet pública a portas de alto risco como SSH (22) e RDP (3389) para prevenir ataques e acessos não autorizados. Se tais portas estiverem expostas, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de rede |
Uma instância NAT Gateway não está totalmente protegida pelo NAT Border Firewall |
Para reduzir a exposição da rede privada à Internet pública, todas as instâncias NAT Gateway devem ser protegidas pelo NAT Border Firewall do Cloud Firewall. Se o Cloud Firewall for usado, mas alguns NAT Gateways não tiverem proteção, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Não suportado. |
Não |
|
Proteção de rede |
O tráfego entre VPCs não está totalmente protegido pelo VPC Border Firewall |
Todo o tráfego entre VPCs deve passar pelo VPC Border Firewall do Cloud Firewall para reduzir riscos de tráfego interno. Se o Cloud Firewall for usado, mas algum tráfego entre VPCs não tiver proteção, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Não suportado. |
Não |
|
Proteção de rede |
O sistema de prevenção de intrusão (IPS) do Cloud Firewall não tem defesa básica ativada |
Ative a defesa básica no sistema de prevenção de intrusão (IPS) do Cloud Firewall. Ela fornece proteção fundamental, incluindo bloqueio de ataques de força bruta, exploits de execução de comandos e comunicações C&C. Se o Cloud Firewall for usado, mas a defesa básica estiver desativada, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Não suportado. |
Não |
|
Proteção de rede |
O sistema de prevenção de intrusão (IPS) do Cloud Firewall não tem inteligência de ameaças ativada |
Ative a inteligência de ameaças no IPS do Cloud Firewall para verificar ameaças e bloquear atividades maliciosas. Se o Cloud Firewall for usado, mas a inteligência de ameaças estiver desativada, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de rede |
O sistema de prevenção de intrusão (IPS) do Cloud Firewall não tem o Modo de Bloqueio ativado |
Configure o IPS do Cloud Firewall no Modo de Bloqueio para interceptar tráfego malicioso e parar intrusões. Se o Cloud Firewall for usado, mas o Modo de Bloqueio estiver desativado, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Esta correção ativa o Modo de Bloqueio para o mecanismo de ameaças. A severidade padrão é Média. |
Não |
|
Proteção de rede |
O sistema de prevenção de intrusão (IPS) do Cloud Firewall não tem correção virtual ativada |
Ative a correção virtual no IPS do Cloud Firewall. Ela fornece proteção em tempo real contra vulnerabilidades críticas e emergenciais na camada de rede, prevenindo exploração sem interromper serviços. Se o Cloud Firewall for usado, mas a correção virtual estiver desativada, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Não suportado. |
Não |
|
Proteção de rede |
O Cloud Firewall tem autorizações disponíveis insuficientes |
Esta verificação confirma se a contagem de autorizações do Cloud Firewall é suficiente. Se o Cloud Firewall for usado, mas o número de ativos de IP público desprotegidos exceder o número de autorizações disponíveis, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Não suportado. |
Não |
|
Proteção de rede |
O Cloud Firewall não tem uma política de negação padrão configurada |
Para segurança de rede, configure uma política de negação padrão (uma política IPv4 com origem e destino definidos como 0.0.0.0/0 e ação definida como Negar). Isso bloqueia todo o tráfego, exceto o tráfego confiável explicitamente permitido. Se o Cloud Firewall for usado, mas nenhuma política de negação padrão estiver configurada, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Não suportado. |
Não |
|
Proteção de rede |
O Cloud Firewall não protege todos os ativos de IP público |
Esta verificação confirma se todos os ativos de IP público estão protegidos pelo Cloud Firewall. Se o Cloud Firewall for usado, mas alguns ativos de IP público não tiverem proteção do Internet Border Firewall, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Não suportado. |
Não |
|
Proteção de rede |
O Cloud Firewall não tem uma política de lista de controle de acesso (ACL) configurada |
Após ativar o firewall, se nenhuma política ACL for configurada, o Cloud Firewall permite todo o tráfego por padrão. Configure políticas ACL para controlar acessos não autorizados. Se o Cloud Firewall for usado, mas não existirem políticas ACL, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Não suportado. |
Não |
|
Proteção de rede |
A largura de banda de proteção do Cloud Firewall é insuficiente |
Esta verificação confirma se a largura de banda de proteção do Cloud Firewall é suficiente. Se o Cloud Firewall for usado, mas a largura de banda de pico nos últimos 30 dias exceder a largura de banda adquirida, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Não suportado. |
Não |
|
Proteção de rede |
O Cloud Firewall não é usado para proteger o tráfego de rede |
O Cloud Firewall é um firewall baseado em SaaS que fornece isolamento de segurança unificado para bordas de Internet, bordas de VPC e bordas de host. É a primeira linha de defesa para cargas de trabalho em nuvem. Se o Cloud Firewall não for usado, a configuração não está em conformidade com as melhores práticas de segurança de rede. |
Não suportado. |
Não |
|
Controle de acesso a dados |
Um bucket OSS tem permissões de escrita pública ativadas |
O OSS suporta acesso público usando políticas de bucket e ACLs. Escrita pública significa que qualquer pessoa pode modificar ou carregar objetos sem permissões ou autenticação. Isso gera riscos de vazamento de dados e acesso malicioso que podem levar a altos custos. Como melhor prática, desative permissões de escrita pública. Acesse dados do OSS apenas usando URLs assinadas ou APIs. Se a política de bucket ou ACL contiver semântica de escrita pública, o bucket está em risco e não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Controle de acesso a dados |
Um bucket OSS tem regras de acesso para conta anônima |
Aplicar o princípio do menor privilégio reduz riscos de segurança e limita o impacto de erros ou comportamentos maliciosos. Se uma política de bucket OSS permitir acesso anônimo, atacantes podem exfiltrar dados. Se contas externas forem comprometidas, seus dados podem ser alterados ou excluídos, ameaçando integridade, confidencialidade e continuidade dos negócios. Como melhor prática, bloqueie acesso anônimo usando políticas. Se a política de bucket conceder acesso a * (todas as contas) com efeito Permitir, ela não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Controle de acesso a dados |
Um bucket OSS tem regras de acesso para contas fora da organização |
Garanta que buckets OSS sejam acessíveis apenas a contas internas para prevenir vazamentos de dados. Se a política de autorização do bucket permitir contas externas, a configuração é não conforme. |
Não suportado. |
Não |
|
Controle de acesso a dados |
Um bucket OSS tem permissões de leitura pública ativadas |
Previna acesso de leitura pública ao conteúdo de buckets OSS para garantir confidencialidade e segurança dos dados. Se permissões de leitura pública estiverem ativadas, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de dados em trânsito |
Um certificado de servidor SLB está em risco de expiração |
Garanta que certificados de servidor SLB não expirem dentro de 15 dias para evitar falhas de criptografia. Se a validade restante for de 15 dias ou menos, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de dados em trânsito |
Uma API no API Gateway com endpoint público não tem HTTPS configurado |
Usar apenas HTTP para APIs públicas representa riscos de segurança de dados. O HTTP transmite dados em texto simples, permitindo que atacantes visualizem informações sensíveis como credenciais e dados privados. Como melhor prática, use HTTPS para APIs públicas e force redirecionamentos de HTTP para HTTPS para garantir transmissão criptografada. Se o domínio do API Gateway não tiver HTTPS configurado, a configuração não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Proteção de dados em trânsito |
Um certificado SSL CDN está próximo da expiração (novo no modelo 3.0) |
Garanta que certificados SSL/TLS vinculados a domínios permaneçam válidos para evitar riscos de segurança e interrupções de serviço. Se o certificado CDN expirar em menos de 15 dias, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de dados em trânsito |
Domínios CDN não têm redirecionamento forçado de HTTP para HTTPS configurado |
Usar apenas HTTP para domínios CDN representa riscos de segurança de dados. O HTTP transmite dados em texto simples, permitindo que atacantes visualizem informações sensíveis como credenciais e dados privados. Como melhor prática, use HTTPS para domínios CDN e force redirecionamentos de HTTP para HTTPS para garantir transmissão criptografada. Se o tipo de redirecionamento forçado do domínio CDN não estiver definido como HTTP→HTTPS, a configuração não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Proteção de dados em trânsito |
Domínios CDN não têm HTTPS configurado |
Usar apenas HTTP para domínios CDN representa riscos de segurança de dados. O HTTP transmite dados em texto simples, permitindo que atacantes visualizem informações sensíveis como credenciais e dados privados. Como melhor prática, use HTTPS para domínios CDN e force redirecionamentos de HTTP para HTTPS para garantir transmissão criptografada. Se a aceleração segura HTTPS não estiver ativada para o domínio CDN, a configuração não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Proteção de dados em trânsito |
Uma instância Elasticsearch não usa HTTPS |
Usar apenas HTTP para Elasticsearch representa riscos de segurança de dados. O HTTP transmite dados em texto simples, permitindo que atacantes visualizem informações sensíveis. Como melhor prática, use HTTPS para acessar o Elasticsearch a partir de aplicações ou clientes para garantir transmissão criptografada. Se a configuração de rede do cluster ativar HTTPS, a configuração está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Proteção de dados em trânsito |
Uma instância SLB não tem listeners HTTPS ativados |
Garanta que o Server Load Balancer (SLB) tenha listeners HTTPS ativados para criptografar dados em trânsito usando TLS. Se listeners HTTPS não estiverem ativados, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de dados em trânsito |
Um certificado no Certificate Management Service está em risco de expiração |
Após a expiração de um certificado SSL, clientes não conseguem verificar a identidade do servidor, causando falhas de acesso ou avisos. Renovações tardias podem reduzir a disponibilidade do serviço, erosionar a confiança do cliente ou causar vazamentos de dados. Reserve tempo suficiente para renovação para evitar interrupções. Se um certificado no Certificate Management Service expirar em 15 dias ou menos, a configuração não está em conformidade com as melhores práticas. |
Não suportado. |
Não |
|
Proteção de dados em trânsito |
Um site ESA não tem TLS v1.2 ativado |
Esta verificação confirma se os sites têm TLS v1.2 ativado para melhorar a segurança. Se não estiver ativado, a configuração não está em conformidade com as melhores práticas de segurança de dados em trânsito. |
Não suportado. |
Não |
|
Proteção de dados em trânsito |
Um site ESA não tem HTTP Strict Transport Security (HSTS) ativado |
Esta verificação confirma se os sites têm HSTS ativado para reduzir riscos de sequestro na primeira visita. Se não estiver ativado, a configuração não está em conformidade com as melhores práticas de segurança de dados em trânsito. |
Não suportado. |
Não |
|
Proteção de dados em trânsito |
Um site ESA não tem HTTPS forçado ativado |
Esta verificação confirma se os sites têm HTTPS forçado ativado para redirecionar solicitações HTTP de clientes para nós de borda ESA via HTTPS. Se não estiver ativado, a configuração não está em conformidade com as melhores práticas de segurança de dados em trânsito. |
Não suportado. |
Não |
|
Mascaramento de dados |
O Data Security Center não tem identificação de dados sensíveis ativada (novo no modelo 3.0) |
Dados sensíveis incluem dados de clientes, documentos técnicos e informações pessoais. O Data Security Center verifica bancos de dados em busca de dados sensíveis usando regras predefinidas e contagens de ocorrências. Bancos suportados incluem MaxCompute, OSS, serviços ApsaraDB (RDS, PolarDB-X, PolarDB, OceanBase e Tablestore) e bancos autogerenciados. Se a identificação de dados sensíveis estiver desativada, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de dados em repouso |
Um cluster PolarDB não tem criptografia transparente de dados (TDE) ativada (novo no modelo 3.0) |
O TDE realiza criptografia e descriptografia de I/O em tempo real em arquivos de dados. Os dados são criptografados antes de serem gravados em disco e descriptografados quando lidos na memória. Se o TDE estiver desativado para PolarDB, podem ocorrer vazamentos de dados, acessos não autorizados ou adulterações. Se o TDE estiver desativado, a configuração é não conforme. |
Não suportado. |
Não |
|
Proteção de dados em repouso |
Uma instância RDS não tem criptografia transparente de dados (TDE) ativada (novo no modelo 3.0) |
Use TDE para criptografia e descriptografia de I/O em tempo real em cenários de conformidade de segurança ou criptografia de dados em repouso. O TDE criptografa dados na camada de banco de dados, impedindo que atacantes leiam dados sensíveis diretamente do armazenamento. Se o TDE estiver desativado para RDS, a configuração é não conforme. |
Não suportado. |
Não |
|
Resposta e recuperação de incidentes de segurança |
O Security Center tem alertas pendentes |
Alertas de segurança indicam ameaças detectadas pelo Security Center em seus servidores ou produtos de nuvem. Tipos de alerta incluem Proteção Contra Adulteração Web, processos anormais, web shells, logins anormais e processos maliciosos. Tratar alertas melhora sua postura de segurança. Se existirem alertas pendentes, a configuração é não conforme. |
Não suportado. |
Não |
|
Resposta e recuperação de incidentes de segurança |
O Security Center não é usado para proteção de segurança (novo no modelo 3.0) |
Ativos em nuvem enfrentam ameaças como vírus, ciberataques, ransomware e exploração de vulnerabilidades. O Security Center fornece gestão de ativos, verificações de configuração e defesa proativa. Adquira serviços de segurança apropriados para construir um sistema de defesa. Se a edição do Security Center for Basic ou inferior, a configuração é não conforme. |
Não suportado. |
Não |
Estabilidade
|
Categoria |
Item de verificação |
Descrição do item de verificação |
Descrição da correção rápida |
Suporta tomada de decisão assistida |
|
Tipos de instância |
O cluster ACK utiliza a Edição Básica de cluster gerenciado |
Os clusters gerenciados do ACK dividem-se em Edição Básica e Edição Pro. A Edição Pro aprimora significativamente a confiabilidade, a segurança e o agendamento do cluster em comparação à Edição Básica, tornando-o mais adequado para executar serviços de grande escala em ambiente de produção. Uma conta é considerada não compatível se não utilizar o tipo de cluster gerenciado na Edição Pro. |
Correção rápida não suportada. |
Não |
|
Tipos de instância |
A instância ECS utiliza um tipo de instância compartilhada ou descontinuada |
Utilizar um tipo de instância compartilhada ou descontinuada para uma instância ECS não garante desempenho computacional estável. O uso de uma família de instâncias ECS compartilhada ou descontinuada é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Tipos de instância |
A instância Elasticsearch utiliza um tipo de instância de desenvolvimento e teste |
Uma instância Elasticsearch com 1 núcleo e 2 GB de memória destina-se apenas a cenários de teste, não sendo adequada para ambientes de produção. O uso de uma instância Elasticsearch com 1 núcleo e 2 GB de memória é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Tipos de instância |
A instância MongoDB utiliza um tipo de instância de nó único |
Quando o MongoDB adota uma arquitetura de nó único, o tempo de recuperação de falhas é longo e não há garantia de SLA. Utilizar uma instância MongoDB que não seja multizona é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Tipos de instância |
A instância RDS utiliza um tipo de instância da série Básica |
Uma instância da série Básica do RDS possui apenas um nó de banco de dados e nenhum nó secundário como backup ativo. Consequentemente, caso o nó falhe inesperadamente ou execute tarefas como reinicialização da instância, alteração de configuração ou atualização de versão, ela ficará indisponível por um longo período. Além disso, os tipos de instância compartilhada e de uso geral na família de instâncias RDS compartilham recursos com outras instâncias na mesma máquina física, sendo adequados apenas para cenários de aplicação com baixos requisitos de estabilidade. Se o negócio exigir alta disponibilidade do banco de dados, recomenda-se utilizar a série Alta Disponibilidade/Cluster para a série do produto e o tipo Dedicado para a família de instâncias. Uma instância RDS é considerada não compatível se a série do produto RDS não utilizar a série Alta Disponibilidade/Cluster, ou se a família de instâncias RDS não utilizar o tipo Dedicado. |
Correção rápida não suportada. |
Não |
|
Tipos de instância |
A instância Redis utiliza um tipo de instância da edição open source |
A Redis Enterprise Edition oferece desempenho superior, mais estruturas de dados e métodos de armazenamento mais flexíveis. Não utilizar a Redis Enterprise Edition é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Tipos de instância |
A instância ApsaraMQ for RocketMQ utiliza um tipo de instância da Edição Standard |
A Edição Standard do ApsaraMQ for RocketMQ utiliza uma instância compartilhada e não é recomendada para uso em ambiente de produção. Utilizar uma edição compartilhada de uma instância RocketMQ é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Versão estável |
O cluster ACK utiliza uma versão expirada do Kubernetes |
A comunidade Kubernetes lança uma versão secundária aproximadamente a cada 4 meses. Recomendamos utilizar uma versão que ainda esteja em manutenção. Clusters com versões expiradas apresentam riscos de segurança e estabilidade. Após a expiração da versão do cluster, você não poderá usufruir dos recursos e correções de bugs suportados pela nova versão do Kubernetes, receber suporte técnico oportuno e eficaz, ou corrigir vulnerabilidades de segurança. Utilizar uma versão de cluster ACK que ainda esteja em manutenção é compatível. |
Correção rápida não suportada. |
Não |
|
Versão estável |
A instância ECS utiliza uma versão de SO expirada |
Utilizar uma versão de SO que não é mais suportada para uma instância ECS é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Versão estável |
A instância Elasticsearch utiliza uma versão não recomendada |
Uma instância Elasticsearch é considerada não compatível se a versão utilizada não estiver dentro do intervalo de versões oficialmente recomendado. |
Correção rápida não suportada. |
Não |
|
Versões estáveis |
A versão do mecanismo MSE é muito antiga |
Utilizar a versão mais recente do mecanismo MSE é fundamental para garantir a continuidade do serviço do MSE. Se a versão do mecanismo for muito antiga, podem ocorrer problemas como defeitos de código impedindo a coleta do GC, estouro de memória causando crescimento contínuo da memória, velocidade de inicialização lenta e defeitos de serialização JSON. Uma conta é considerada não compatível se a versão do mecanismo MSE-ZooKeeper ou MSE-ANS, ou a versão do cliente MSE-ANS, for muito antiga. |
Correção rápida não suportada. |
Não |
|
Versões estáveis |
A versão do gateway MSE-Ingress é muito antiga |
Utilizar a versão mais recente do Ingress é fundamental para garantir a continuidade do serviço do gateway. Se a versão for muito antiga, podem ocorrer problemas como riscos de segurança ou estabilidade, além de possíveis imprecisões na lista de instâncias para assinatura de serviços Nacos. Uma conta é considerada não compatível se a versão do MSE-Ingress for muito antiga. |
Correção rápida não suportada. |
Não |
|
Versões estáveis |
A versão principal do banco de dados MySQL da instância RDS é muito antiga (Novidade no Modelo 3.0) |
Utilizar uma versão do MySQL cujo ciclo de vida cessou ou está prestes a cessar expõe o sistema a problemas como riscos de segurança, gargalos de desempenho, questões de compatibilidade e falta de suporte técnico. Atualizar oportunamente para uma versão suportada do MySQL fornece os patches de segurança mais recentes, melhorias de desempenho e aprimoramentos de recursos, o que reduz os riscos de O&M e melhora a confiabilidade geral do sistema. Uma instância RDS é considerada não compatível se utilizar a versão 5,5 ou 5,6. |
Correção rápida não suportada. |
Não |
|
Versão estável |
A função do Function Compute (FC) 2.0 utiliza um runtime obsoleto (Novidade no Modelo 3.0) |
À medida que as versões de runtime evoluem, o Function Compute deixa de manter alguns runtimes e não fornece mais suporte técnico ou atualizações de segurança para eles. Recomendamos migrar as funções para o runtime suportado mais recente para obter suporte técnico e atualizações de segurança. Uma função FC 2.0 é considerada não compatível se utilizar qualquer um dos seguintes runtimes: nodejs12, nodejs10, nodejs8, dotnetcore2.1, python2.7, nodejs6 ou nodejs4.4. |
Correção rápida não suportada. |
Não |
|
Versões estáveis |
A inspeção do cluster ACK identifica que a versão do componente Kubelet em um nó está atrasada em relação ao plano de controle (Novidade no Modelo 3.0) |
Se a versão do componente Kubelet em um nó do cluster ACK estiver atrasada em relação ao plano de controle, podem ocorrer problemas de compatibilidade. O plano de controle, como o API Server, pode não conseguir se comunicar com uma versão mais antiga do Kubelet devido a novos recursos ou atualizações de protocolo. Isso pode levar a status anormais de nós, falhas no agendamento de Pods ou nós marcados como indisponíveis. Além disso, versões mais antigas do Kubelet podem conter vulnerabilidades de segurança não corrigidas, o que aumenta o risco de ataques aos nós e dificulta a capacidade de atualização geral do cluster. Para restaurar a estabilidade da comunicação e eliminar riscos de segurança, é necessário atualizar o Kubelet para uma versão compatível. Um nó com uma versão do Kubelet atrasada em relação ao plano de controle é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Versão estável |
O banco de dados do cluster PolarDB não utiliza uma versão secundária estável |
Um banco de dados PolarDB é considerado não compatível se o status de sua versão secundária não for Estável ou Beta. |
Esta correção ativa a atualização automática da versão secundária para a instância especificada. Quando sua versão secundária do mecanismo for inferior à versão secundária mais recente do mecanismo, o sistema emitirá periodicamente tarefas ativas de O&M para atualizar a versão secundária do mecanismo. A operação de atualização automática é executada dentro da janela de manutenção definida por você. Durante o processo de atualização, o proxy de banco de dados (PolarProxy) ou o mecanismo de kernel (DB) é reiniciado, o que pode causar uma conexão transitória. Execute a operação de atualização durante horários de baixa demanda e garanta que sua aplicação possua um mecanismo de reconexão automática. |
Não |
|
Versão estável |
A instância RDS não tem a atualização automática da versão secundária do mecanismo ativada (Novidade no Modelo 3.0) |
O ApsaraDB RDS suporta atualização automática ou manual da versão secundária do mecanismo. Quando a versão secundária do mecanismo é inferior à versão secundária mais recente, o sistema emite periodicamente tarefas ativas de O&M para atualizar a versão secundária do mecanismo. A instância obtém a versão mais recente, incluindo melhorias de desempenho, suporte a novos recursos e correções de problemas de segurança, o que garante a otimização contínua e a segurança do serviço de banco de dados. Uma instância RDS é considerada não compatível se não tiver a atualização automática da versão secundária do mecanismo ativada. |
Esta correção ativa automaticamente a atualização automática da versão secundária do mecanismo para a instância RDS selecionada. Quando a versão secundária do mecanismo da instância RDS for inferior à versão secundária mais recente do mecanismo, o sistema emitirá periodicamente tarefas ativas de O&M para atualizar a versão secundária do mecanismo. A operação de atualização automática é executada dentro da janela de manutenção definida por você. As informações da tarefa de atualização emitidas pelo sistema são notificadas através de canais como mensagens de texto e e-mails configurados no Message Center. |
Não |
|
Versão estável |
A instância Redis não foi atualizada para a versão secundária mais recente |
Uma instância Redis é considerada não compatível se não tiver sido atualizada para a versão secundária mais recente. |
Esta correção ativa a atualização automática da versão secundária para a instância selecionada. Após a ativação, o sistema verifica periodicamente o status de lançamento da versão. Se uma nova versão for encontrada, ela será atualizada automaticamente dentro do período atualizável de 60 dias. Ao atualizar a versão do banco de dados, a instância primeiro atualiza a instância secundária (Réplica) ou prepara uma nova instância. No horário de execução especificado, um failover primário/secundário ou failover de instância é realizado para concluir a operação de atualização. Durante a fase de failover da instância, a instância fica em estado somente leitura por até 60 segundos enquanto aguarda a sincronização completa dos dados, e ocorre uma conexão transitória de alguns segundos. Garanta que sua aplicação possua um mecanismo de reconexão. |
Não |
|
Riscos de expiração |
A instância AnalyticDB for MySQL Data Warehouse Edition está em risco de expiração |
Uma instância AnalyticDB for MySQL Data Warehouse Edition é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento da verificação e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura ADB selecionado. |
Não |
|
Riscos de expiração |
A instância Anti-DDoS está em risco de expiração |
Uma instância DDoS é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento atual e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura DDoSCOO selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
A instância ECS está em risco de expiração |
Uma instância de assinatura ECS é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento da verificação e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura ECS selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
A instância EIP está em risco de expiração |
Uma instância de assinatura EIP é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento da verificação e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura EIP selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
A instância KMS está em risco de expiração (Novidade no Modelo 3.0) |
Garanta a renovação oportuna das instâncias de assinatura KMS para evitar interrupções nos negócios devido à expiração. Uma instância de assinatura KMS é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento da verificação e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura KMS selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
A instância MongoDB está em risco de expiração |
Uma instância de assinatura MongoDB é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento da verificação e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura MongoDB selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
O cluster PolarDB está em risco de expiração |
Uma instância de assinatura PolarDB é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento da verificação e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura PolarDB selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
A instância PolarDB-X está em risco de expiração |
Uma instância PolarDB-X 1.0 ou PolarDB-X 2.0 é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento atual e a renovação automática não estiver ativada. |
Correção rápida não suportada. |
Não |
|
Riscos de expiração |
A instância RDS está em risco de expiração |
Uma instância de assinatura RDS é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento da verificação e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura RDS selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
A instância Redis está em risco de expiração |
Uma instância de assinatura Redis é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento da verificação e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura Redis selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
A instância SLB está em risco de expiração |
Uma instância de assinatura SLB é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento da verificação e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura SLB selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
O VPN Gateway está em risco de expiração (Novidade no Modelo 3.0) |
Garanta a renovação oportuna das instâncias de assinatura do VPN Gateway para evitar interrupções nos negócios devido à expiração. Uma instância de assinatura do VPN Gateway é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento da verificação e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura VPN selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
O plano de largura de banda CEN está em risco de expiração |
Um plano de largura de banda da Cloud Enterprise Network é considerado não compatível se estiver previsto para expirar em menos de 7 dias a partir do momento atual e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura CEN selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
A instância de largura de banda compartilhada está em risco de expiração |
Uma instância de largura de banda compartilhada é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento atual e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso CBWP selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Riscos de expiração |
A instância Bastionhost está em risco de expiração |
Uma instância Bastionhost é considerada não compatível se estiver prevista para expirar em menos de 7 dias a partir do momento da verificação e a renovação automática não estiver ativada. |
Esta correção ativa a renovação automática para o recurso de instância de assinatura Bastionhost selecionado. Após a ativação da renovação automática, o recurso entra em vigor no dia seguinte. Ative a renovação automática pelo menos 2 dias antes da expiração da instância de assinatura. Se sua instância estiver prevista para expirar no dia seguinte, recomendamos acessar o console do produto para renovar manualmente. O ciclo de renovação automática baseia-se na duração de renovação automática definida. Por exemplo, se você selecionar uma duração de renovação de 1 mês, a instância será renovada automaticamente por 1 mês antes de cada expiração. Garanta que o saldo da sua conta, vouchers em dinheiro ou outros métodos de pagamento sejam suficientes para cobrir o valor da renovação. |
Não |
|
Proteção contra exclusão |
A proteção contra exclusão não está ativada para o cluster ACK |
Um cluster ACK é considerado não compatível se a proteção contra exclusão não estiver ativada. |
Esta correção ativa a proteção contra exclusão para o recurso selecionado. O recurso não pode ser liberado através do console, API ou linha de comando. Para liberar a instância, primeiro acesse a página de detalhes da instância para desativar a chave de proteção contra exclusão. |
Não |
|
Proteção contra exclusão |
A proteção contra exclusão não está ativada para a instância ALB |
Uma instância ALB é considerada não compatível se a proteção contra exclusão não estiver ativada. |
Esta correção ativa a proteção contra exclusão para o recurso selecionado. O recurso não pode ser liberado através do console, API ou linha de comando. Para liberar a instância, primeiro acesse a página de detalhes da instância para desativar a chave de proteção contra exclusão. |
Não |
|
Proteção contra exclusão |
A proteção contra exclusão não está ativada para a instância EIP |
Uma instância EIP é considerada não compatível se a proteção contra exclusão não estiver ativada. |
Esta correção ativa a proteção contra exclusão para o recurso selecionado. O recurso não pode ser liberado através do console, API ou linha de comando. Para liberar a instância, primeiro acesse a página de detalhes da instância para desativar a chave de proteção contra exclusão. |
Não |
|
Proteção contra exclusão |
A proteção contra liberação não está ativada para a instância MongoDB |
Uma instância MongoDB é considerada não compatível se a proteção contra liberação não estiver ativada. |
Esta correção ativa a proteção contra exclusão para o recurso selecionado. O recurso não pode ser liberado através do console, API ou linha de comando. Para liberar a instância, primeiro acesse a página de detalhes da instância para desativar a chave de proteção contra exclusão. |
Não |
|
Proteção contra exclusão |
O bloqueio de cluster não está ativado para o cluster PolarDB |
Uma instância PolarDB é considerada não compatível se o bloqueio de cluster não estiver ativado. |
Esta correção ativa a proteção contra exclusão para o recurso selecionado. O recurso não pode ser liberado através do console, API ou linha de comando. Para liberar a instância, primeiro acesse a página de detalhes da instância para desativar a chave de proteção contra exclusão. |
Não |
|
Proteção contra exclusão |
A proteção contra liberação não está ativada para a instância RDS |
Uma instância RDS é considerada não compatível se a proteção contra liberação não estiver ativada. |
Esta correção ativa a proteção contra exclusão para o recurso selecionado. O recurso não pode ser liberado através do console, API ou linha de comando. Para liberar a instância, primeiro acesse a página de detalhes da instância para desativar a chave de proteção contra exclusão. |
Não |
|
Proteção contra exclusão |
A proteção contra exclusão não está ativada para a instância SLB |
Uma instância SLB é considerada não compatível se a proteção contra exclusão não estiver ativada. |
Esta correção ativa a proteção contra exclusão para o recurso selecionado. O recurso não pode ser liberado através do console, API ou linha de comando. Para liberar a instância, primeiro acesse a página de detalhes da instância para desativar a chave de proteção contra exclusão. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que a instância CLB vinculada ao API Server não existe (Novidade no Modelo 3.0) |
Se um API Server de cluster ACK não estiver vinculado a uma instância Classic Load Balancer (CLB), resulta na falta de um ponto de entrada de tráfego para o serviço de API. Clientes externos como kubectl não conseguem acessar o API Server através de balanceamento de carga, o que interrompe completamente o gerenciamento do cluster. Componentes do cluster como kubelet e controladores podem causar status anormais de nós, falhas no agendamento de Pods e indisponibilidade de serviços devido à incapacidade de estabelecer comunicação estável. Ao mesmo tempo, o nó do API Server expõe diretamente seu endereço IP, perdendo capacidades de distribuição de tráfego e failover, o que representa um risco de ponto único de falha e aumenta a ameaça de acesso não autorizado ou ataques DDoS. Uma instância CLB deve ser criada e vinculada imediatamente para restaurar a alta disponibilidade e o acesso seguro. Um cluster ACK é considerado não compatível se seu API Server não estiver vinculado a uma instância CLB. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que a instância CLB vinculada ao API Server está em estado anormal (Novidade no Modelo 3.0) |
Se a instância CLB vinculada a um API Server de cluster ACK estiver em estado anormal, causa falha no encaminhamento de tráfego do serviço de API. Clientes como kubectl não conseguem estabelecer uma conexão estável, o que bloqueia completamente o gerenciamento do cluster. Componentes internos como kubelet e controladores causam status anormais de nós, estagnação no agendamento de Pods e indisponibilidade de serviços devido à interrupção da comunicação. Simultaneamente, a falha na verificação de integridade do CLB pode fazer com que o tráfego se concentre em nós defeituosos, exacerbando os riscos de ponto único de falha. Se o estado anormal for acompanhado por erros de configuração de segurança, como falta de criptografia ou portas expostas, pode levar a acesso não autorizado ou ataques man-in-the-middle. O status de integridade do CLB deve ser reparado imediatamente e a política de segurança verificada para evitar paralisia do cluster e violações de dados. Um cluster ACK é considerado não compatível se a instância CLB vinculada ao seu API Server estiver em estado anormal. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que a configuração do listener de porta do CLB vinculado ao API Server é anormal (Novidade no Modelo 3.0) |
Se a configuração do listener de porta do CLB vinculado a um API Server de cluster ACK for anormal, causa interrupção no acesso ao serviço de API. Clientes como kubectl não conseguem se conectar ao cluster, e as operações de O&M falham completamente. Ao mesmo tempo, componentes internos como kubelet e controladores causam status anormais de nós, falhas no agendamento de Pods e indisponibilidade de serviços devido à incapacidade de se comunicar com o API Server. Se o protocolo do listener estiver incorreto ou restrições de grupo de segurança estiverem ausentes, pode levar a riscos de acesso não autorizado ou sequestro de tráfego. A configuração da porta do listener deve ser reparada imediatamente, e o tipo de protocolo e a política de segurança devem ser verificados para evitar paralisia do cluster e violações de dados. Um cluster ACK é considerado não compatível se a configuração do listener de porta do CLB vinculado ao seu API Server for anormal. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que o número de servidores backend para o serviço CoreDNS é 0 (Novidade no Modelo 3.0) |
Se o número de servidores backend para o CoreDNS em um cluster ACK for 0, causa falha completa na descoberta de serviços. A comunicação entre serviços dentro do cluster, como chamadas de microsserviços e acesso a banco de dados, é interrompida, e as aplicações não conseguem resolver endereços através de nomes de serviço, o que afeta diretamente a disponibilidade do negócio. Também causa riscos à estabilidade do cluster. Um cluster ACK é considerado não compatível se o número de servidores backend para seu serviço CoreDNS for 0. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A taxa de erro 5xx do ALB é muito alta (Novidade no Modelo 3.0) |
Se a taxa de erro 5xx de uma instância ALB continuar excedendo um limiar especificado por um período de tempo, indica que o serviço backend está frequentemente sofrendo erros internos. Isso pode ser causado por exceções na aplicação, recursos insuficientes, erros de configuração ou falhas em serviços dependentes. Leva diretamente a um declínio na experiência do usuário, aumento no risco de interrupção dos negócios e afeta a estabilidade e disponibilidade do sistema. Uma instância ALB é considerada não compatível se sua taxa de erro 5xx for maior ou igual a 80% por pelo menos 8 horas dentro de um determinado intervalo de tempo no passado. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A taxa de falha de handshake TLS do ALB é muito alta (Novidade no Modelo 3.0) |
Uma alta taxa de falha de handshake TLS do ALB pode indicar que existem problemas na comunicação criptografada entre o cliente e o servidor, como erros de configuração de certificado, versões de protocolo incompatíveis, conjuntos de chaves incompatíveis ou o cliente usando um algoritmo de criptografia não suportado. Isso não só causa falha no acesso do usuário e afeta a disponibilidade do negócio, mas também pode expor vulnerabilidades de segurança e aumentar o risco de ataques man-in-the-middle. Uma instância ALB é considerada não compatível se sua taxa de falha de handshake TLS for maior ou igual a 80% por pelo menos 8 horas dentro de um determinado intervalo de tempo no passado. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A taxa de falha de conexão do ALB é muito alta (Novidade no Modelo 3.0) |
Uma alta taxa de falha de conexão para um Application Load Balancer (ALB) pode indicar que o serviço backend está anormal, a rede está instável ou a configuração está incorreta. Isso pode levar a falha no acesso do usuário, interrupção dos negócios e declínio na experiência do usuário. Ao inspecionar a métrica de taxa de falha de conexão do ALB, é possível descobrir e localizar prontamente a causa raiz do problema, o que melhora a disponibilidade e estabilidade do sistema, otimiza a eficiência do agendamento de tráfego e garante a continuidade dos negócios e a qualidade do serviço. Isso traz capacidades de entrega de aplicações em nuvem mais confiáveis para os clientes. Uma instância ALB é considerada não compatível se sua taxa de falha de conexão for maior ou igual a 80% por pelo menos 8 horas dentro de um determinado intervalo de tempo no passado. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A configuração do nome de domínio de origem OSS no nome de domínio CDN é anormal (Novidade no Modelo 3.0) |
Se a configuração do nome de domínio de origem em um nome de domínio CDN não existir, causa falha nas solicitações de recursos e afeta as funções do negócio. Simultaneamente, a falha na busca de origem faz com que o CDN tente repetidamente, aumentando a sobrecarga desnecessária da rede. Um nome de domínio CDN é considerado não compatível se utilizar um nome de domínio OSS em suas informações de origem, e o status do recurso do bucket OSS correspondente não for "Em Uso". Nomes de domínio CDN que não utilizam um nome de domínio OSS como informação de origem não estão incluídos no escopo de detecção. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
O nome de domínio OSS configurado no registro CNAME na resolução de nome de domínio DNS é anormal (Novidade no Modelo 3.0) |
Se um nome de domínio OSS incorreto estiver configurado no registro CNAME da resolução de nome de domínio DNS, o acesso a recursos através desse nome de domínio causará falha no carregamento normal dos recursos, afetando as funções normais do negócio. Um nome de domínio DNS é considerado não compatível se um registro CNAME no DNS estiver configurado com um nome de domínio OSS, e o bucket OSS correspondente não estiver "Em Uso". Nomes de domínio DNS que não utilizam um nome de domínio OSS em seus registros CNAME não estão incluídos no escopo de detecção. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A imagem personalizada configurada no modelo de inicialização da instância ECS é anormal (Novidade no Modelo 3.0) |
Um modelo de inicialização de instância é uma ferramenta para criar instâncias rapidamente, melhorando a eficiência e a experiência do usuário. Quando a imagem personalizada configurada no modelo de inicialização não existe, causa falha na execução do modelo de inicialização. Um modelo de inicialização de instância ECS é considerado não compatível se a imagem personalizada associada a ele não for um recurso "Em Uso". |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
O balanceador de carga associado ao grupo de dimensionamento ESS é anormal (Novidade no Modelo 3.0) |
Após um grupo de dimensionamento ser associado a uma instância de balanceador de carga, independentemente de o grupo de dimensionamento criar instâncias automaticamente ou instâncias serem adicionadas manualmente ao grupo, as instâncias são adicionadas automaticamente aos servidores backend da instância do balanceador de carga. Se o balanceador de carga ou o grupo de servidores do balanceador de carga não existir, causa falha no dimensionamento do grupo. Um grupo Auto Scaling é considerado não compatível se o Classic Load Balancer ou Application Load Balancer associado a ele não for um recurso "Em Uso". |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
O atraso entre a instância somente leitura RDS e a instância primária é muito grande (Novidade no Modelo 3.0) |
Uma instância somente leitura RDS utiliza a tecnologia nativa de replicação baseada em log do MySQL (replicação assíncrona ou semissíncrona), portanto, inevitavelmente há uma latência de sincronização. A latência causa inconsistência de dados entre a instância somente leitura e a instância primária, levando a problemas nos negócios. Além disso, a latência também pode causar acúmulo de logs, consumindo rapidamente o espaço da instância somente leitura. Uma instância somente leitura RDS é considerada não compatível se o atraso máximo entre ela e a instância primária exceder 60 segundos dentro de 7 dias. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
Número insuficiente de IPs disponíveis na instância VPC (Novidade no Modelo 3.0) |
Garanta que o vSwitch da VPC tenha um número suficiente de IPs disponíveis para evitar a impossibilidade de expandir o negócio devido a recursos insuficientes. Um vSwitch da VPC é considerado não compatível se o número de IPs IPv4 disponíveis for menor ou igual a um valor especificado (o padrão é 10). |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A instância ECS foi desligada devido a pagamento em atraso ou banimento de segurança |
Um desligamento passivo de uma instância ECS causa interrupção do serviço, perda de dados e inconsistência de dados, além de afetar o desempenho do sistema ou criar riscos de segurança. Uma conta é considerada em risco se houver uma instância ECS na conta atual que tenha sido desligada devido a pagamento em atraso ou banimento de segurança. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que o status backend da instância CLB do API Server é anormal (Novidade no Modelo 3.0) |
Se o status backend de uma instância CLB do API Server de um cluster ACK for anormal, causa interrupção na comunicação do plano de controle, levando diretamente a uma falha completa no gerenciamento do cluster. Clientes como kubectl não conseguem acessar o API Server, tornando impossível realizar operações como implantar aplicações e visualizar status. Simultaneamente, componentes como kubelet e controladores desencadeiam status anormais de nós, falhas no agendamento de Pods e falhas no mecanismo de recuperação automática devido à desconexão com o API Server. Isso faz com que a estabilidade do cluster colapse e os serviços de negócio sejam interrompidos devido à inacessibilidade da API. Além disso, ferramentas de monitoramento como Prometheus não conseguem coletar dados de métricas, tornando impossível alertar e solucionar anomalias prontamente. Mais gravemente, a indisponibilidade prolongada do API Server pode causar inconsistência entre o status do cluster e os dados armazenados no etcd, levando a perda de dados ou anomalias operacionais. A configuração do CLB, o status de integridade dos nós backend e a conectividade de rede devem ser verificados imediatamente para garantir a distribuição normal de tráfego e evitar um colapso completo do cluster. Um cluster ACK é considerado não compatível se o status backend de sua instância CLB do API Server for anormal. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que o APIService está indisponível (Novidade no Modelo 3.0) |
Se um APIService de cluster ACK estiver indisponível, causa falha na função de API estendida. Recursos personalizados como CRDs não conseguem se comunicar com o plano de controle, levando a anomalias de gerenciamento para componentes que dependem de APIs estendidas, como Operators e service meshes. Solicitações de API, como atualizações de status de recursos e entrega de configurações, falham devido à interrupção do serviço, o que pode causar perda de dados de monitoramento, falha em políticas automáticas ou erros em comandos de gerenciamento de cluster. Se APIs estendidas principais, como Admission Webhooks, forem afetadas, isso bloqueia o processo de criação de recursos, exacerbando o risco de bloqueio operacional do cluster. O APIService deve ser restaurado urgentemente para evitar paralisia de funções críticas e inconsistência de dados. Um cluster ACK é considerado não compatível se seu APIService estiver indisponível. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que o método de faturamento do Serviço LoadBalancer é inconsistente com a instância real (Novidade no Modelo 3.0) |
Se o método de faturamento de um serviço LoadBalancer de cluster ACK não corresponder à instância real, causa anomalias de faturamento. Isso pode levar a provisionamentos inesperados, como pagamento conforme o uso em vez da assinatura esperada, ou liberação inesperada de recursos, como não renovar uma assinatura após a expiração, causando interrupção do serviço. Simultaneamente, a gestão caótica de recursos interfere nas políticas de dimensionamento automático, aumentando custos e riscos de O&M. A configuração do método de faturamento deve ser calibrada imediatamente para evitar discrepâncias de faturamento e declínio na disponibilidade do negócio. Um cluster ACK é considerado não compatível se o método de faturamento de seu serviço LoadBalancer for inconsistente com a instância real. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que o ID da instância de certificado do Serviço LoadBalancer é inconsistente com a instância real (Novidade no Modelo 3.0) |
Se o ID da instância de certificado de um serviço LoadBalancer de cluster ACK não corresponder ao certificado realmente vinculado, causa falha na configuração TLS. Isso leva à rejeição de conexão do serviço HTTPS ou avisos de segurança, e interrupção do acesso do usuário. Um certificado inválido pode expor tráfego não criptografado, aumentando o risco de ataques man-in-the-middle. Simultaneamente, verificações de integridade anormais julgam erroneamente o status dos serviços backend, exacerbando o caos na distribuição de tráfego. A configuração do certificado deve ser sincronizada imediatamente para restaurar a comunicação segura e a disponibilidade do serviço. Um cluster ACK é considerado não compatível se o ID da instância de certificado de seu serviço LoadBalancer for inconsistente com a instância real. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica um Pod CoreDNS anormal (Novidade no Modelo 3.0) |
Um Pod CoreDNS anormal em um cluster ACK torna o serviço de resolução DNS instável. A comunicação entre serviços através de nomes de domínio pode sofrer timeout ou falhar, levando a interrupções nas chamadas da aplicação. Um Pod anormal pode fazer com que o controlador reinicie continuamente, aumentando a carga no plano de controle e ocupando recursos do nó sem fornecer serviços eficazes. Se o Pod estiver anormal devido a erros de configuração ou vulnerabilidades de imagem, pode causar sequestro de DNS ou poluição de resolução, levando a erros de roteamento de serviço ou violações de dados. O status do Pod deve ser verificado e a configuração reparada imediatamente para restaurar a confiabilidade do serviço DNS. Um cluster ACK é considerado não compatível se existir um Pod CoreDNS anormal. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que o status do componente elástico é anormal (Novidade no Modelo 3.0) |
Se o status do componente elástico de um cluster ACK for anormal, causa falha em mecanismos como dimensionamento automático e recuperação automática de falhas. Ele não consegue dimensionar horizontalmente dinamicamente durante alta carga, levando a gargalos de recursos, atrasos na resposta do serviço ou interrupções. Não consegue substituir automaticamente nós ou Pods defeituosos, exacerbando riscos de disponibilidade. Simultaneamente, o cluster não consegue otimizar a alocação de recursos de acordo com as políticas, resultando em desperdício de custos ou declínio na eficiência de O&M. A longo prazo, pode bloquear processos de negócio críticos. O status do componente elástico deve ser reparado urgentemente para restaurar as capacidades adaptativas do cluster. Um cluster ACK é considerado não compatível se o status de seu componente elástico for anormal. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que o vSwitch do pool de nós está indisponível (Novidade no Modelo 3.0) |
Se um vSwitch de pool de nós de um cluster ACK estiver indisponível, causa interrupção na comunicação de rede entre nós. Pods e serviços não conseguem interagir entre nós, levando a falhas na descoberta de serviços ou estagnação na transmissão de dados. A comunicação entre o plano de controle e os nós workers é desconectada, e os nós são marcados como indisponíveis, o que pode desencadear evicções errôneas ou redução anormal do tamanho do cluster. Simultaneamente, os nós não conseguem acessar armazenamento externo, banco de dados e outros recursos, causando paralisia nas funções da aplicação. O risco de particionamento de rede é exacerbado, podendo causar split-brain no cluster ou inconsistência de dados. Do ponto de vista de O&M, torna-se impossível localizar falhas em tempo hábil devido à interrupção dos dados de monitoramento. O serviço vSwitch deve ser restaurado urgentemente para garantir a conectividade de rede. Um cluster ACK é considerado não compatível se o vSwitch de seu pool de nós estiver indisponível. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que o grupo de dimensionamento do pool de nós está indisponível (Novidade no Modelo 3.0) |
Se um grupo de dimensionamento de pool de nós de um cluster ACK estiver indisponível, causa a perda completa das capacidades de dimensionamento automático do cluster. Ele não consegue dimensionar horizontalmente dinamicamente durante alta carga, levando à exaustão de recursos dos nós, falhas no agendamento de Pods ou atrasos na resposta do serviço. Não consegue reduzir a escala durante baixa carga, resultando em ociosidade de recursos e desperdício de custos. O mecanismo de substituição automática para nós defeituosos falha, podendo causar longos períodos de inatividade dos nós e exacerbando o risco de ponto único de falha no cluster. Simultaneamente, um grupo de dimensionamento anormal dificulta a capacidade do cluster de responder elasticamente a picos repentinos de tráfego ou necessidades de manutenção. A longo prazo, leva a um declínio na estabilidade do serviço e na eficiência de O&M. O status do grupo de dimensionamento deve ser reparado imediatamente para restaurar as capacidades elásticas do cluster. Um cluster ACK é considerado não compatível se o grupo de dimensionamento de seu pool de nós estiver indisponível. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que a configuração de dimensionamento do pool de nós está indisponível (Novidade no Modelo 3.0) |
Se uma configuração de dimensionamento de pool de nós de um cluster ACK estiver indisponível, impede que o cluster ajuste automaticamente o número de nós. Ele não consegue aumentar a escala durante alta carga, levando à exaustão de recursos, falhas no agendamento de Pods ou interrupções de serviço. Não consegue reduzir a escala durante baixa carga, resultando em desperdício de recursos e aumento de custos. Simultaneamente, o mecanismo de substituição automática para nós defeituosos falha, podendo causar indisponibilidade prolongada dos nós e reduzir a alta disponibilidade do cluster. A longo prazo, também causa falha em políticas automáticas como HPA (Horizontal Pod Autoscaler), levando a um estado desequilibrado do cluster e aumento nos custos de O&M. A configuração de dimensionamento deve ser reparada imediatamente para restaurar as capacidades elásticas. Um cluster ACK é considerado não compatível se a configuração de dimensionamento de seu pool de nós estiver indisponível. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A inspeção do cluster ACK identifica que o grupo de segurança do pool de nós está indisponível (Novidade no Modelo 3.0) |
Se um grupo de segurança de pool de nós de um cluster ACK estiver indisponível, causa falha nas regras de acesso à rede. A comunicação entre componentes do cluster, como kubelet e API Server, e a descoberta de serviços entre Pods podem ser interrompidas devido ao bloqueio de portas ou ausência de regras. Simultaneamente, tráfego não autorizado pode romper a proteção, aumentando o risco de intrusão nos nós ou ataques DDoS. Se as regras de saída estiverem anormais, os nós não conseguem acessar armazenamento externo, repositórios de imagens ou serviços de monitoramento, levando a falhas nas chamadas de serviços dependentes. A falha no grupo de segurança também faz com que os nós sejam isolados equivocadamente, afetando o agendamento de Pods e a continuidade dos negócios. A configuração das regras deve ser reparada imediatamente para restaurar o isolamento de rede e a segurança da comunicação. Um cluster ACK é considerado não compatível se o grupo de segurança de seu pool de nós estiver indisponível. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A taxa de erro 4xx do ALB é muito alta (Novidade no Modelo 3.0) |
Se a taxa de erro 4xx de uma instância ALB continuar excedendo um limiar especificado por um período de tempo, geralmente significa que há muitas exceções nas solicitações do cliente, como solicitações inválidas, erros de parâmetro, falhas de autenticação ou alta frequência de acesso, como ataques DDoS. Isso não só afeta a experiência de usuários normais, mas também pode expor defeitos de design de interface do sistema ou riscos de segurança. Uma instância ALB é considerada não compatível se sua taxa de erro 4xx for maior ou igual a 80% por pelo menos 8 horas dentro de um determinado intervalo de tempo no passado. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A instância CEN não está configurada com verificação de integridade VBR (Novidade no Modelo 3.0) |
O recurso de verificação de integridade da Cloud Enterprise Network detecta a conectividade do circuito Express Connect associado a uma instância VBR. Em cenários onde existem rotas redundantes entre a Cloud Enterprise Network e um data center, a verificação de integridade suporta a troca automática para uma rota disponível após detectar uma falha no circuito Express Connect, garantindo transmissão ininterrupta de tráfego. Uma instância CEN é considerada não compatível se uma VBR associada a ela não estiver configurada com uma verificação de integridade. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
O registro SPF na resolução de e-mail de domínio DNS é anormal (Novidade no Modelo 3.0) |
SPF é um protocolo de validação de e-mail baseado em DNS usado para definir quais servidores de e-mail, como endereços IP ou nomes de domínio, estão autorizados a enviar e-mails em nome de um domínio. Quando um servidor de e-mail recebe uma mensagem, ele verifica o endereço IP do remetente em relação à lista permitida no registro SPF para determinar se o e-mail é legítimo. Definir um valor SPF válido e razoável pode prevenir falsificação de e-mail, reduzir o risco de spam e melhorar a taxa de entrega de e-mails. Para cada registro MX em um domínio DNS, verifique se existe pelo menos um registro TXT com um valor SPF válido que comece com v=spf1. Um domínio DNS que não atenda às condições acima é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A instância ECS possui eventos de O&M pendentes |
Deixar de responder e tratar eventos agendados de O&M para ECS em tempo hábil pode fazer com que a instância ECS reinicie durante horários de pico de negócios, afetando a estabilidade dos serviços na instância ECS. Uma conta é considerada em risco se houver eventos de O&M ECS pendentes com status de Consulta, Agendado ou Executando. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
O bucket OSS não está definido com um nome de domínio personalizado |
Usar um nome de domínio personalizado pode melhorar a imagem da marca e o profissionalismo, além de aumentar a estabilidade. Um nome de domínio personalizado pode ser vinculado via CNAME para obter aceleração CDN, melhorando o desempenho de acesso. Também suporta acesso seguro HTTPS, aprimorando a segurança na transmissão de dados. Um bucket OSS é considerado não compatível se não estiver definido com um nome de domínio personalizado. |
Correção rápida não suportada. |
Não |
|
Inspeção de riscos |
A replicação de dados para a instância RDS for PostgreSQL não usa modo síncrono ou semissíncrono (Novidade no Modelo 3.0) |
O RDS for PostgreSQL suporta três modos de replicação de dados: assíncrono, síncrono e semissíncrono. O modo assíncrono tem a velocidade de resposta mais rápida, mas é adequado apenas para cenários com baixos requisitos de persistência de dados. Pode ocorrer perda de dados quando o banco de dados falha, representando um risco de persistência. Uma instância RDS for PostgreSQL é considerada não compatível se usar o modo assíncrono para replicação de dados (parâmetro synchronous_commit desativado). |
Esta correção altera o modo de replicação de dados do banco de dados RDS for PostgreSQL para o modo semissíncrono ou síncrono. O modo síncrono fornece o nível máximo de proteção e é adequado para cenários com requisitos extremamente altos de persistência de dados, mas a velocidade de resposta é lenta. O modo semissíncrono fornece o nível mais alto de proteção de disponibilidade, equilibrando persistência de dados e velocidade de resposta. Para alterar o modo de replicação de dados para semissíncrono, a versão do kernel da instância deve ser 20220228 ou posterior. A ação de modificar o parâmetro é executada dentro da janela de manutenção definida para a instância. |
Não |
|
Inspeção de riscos |
O uso de conexões da instância Redis é muito alto (Novidade no Modelo 3.0) |
Se o uso de conexões de uma instância Redis continuar excedendo um limiar especificado por um período de tempo, indica que os recursos de conexão atuais estão próximos ou atingiram seu limite. Isso pode impedir que novos clientes estabeleçam conexões, causar rejeição de solicitações ou aumentar a latência de resposta, afetando o desempenho e a estabilidade do negócio. Essa situação também pode indicar problemas como vazamentos de conexão, configurações inadequadas de pool de conexões ou pressão súbita de tráfego. Uma instância Redis é considerada não compatível se seu uso médio de conexões for maior ou igual a 50% por pelo menos 8 horas dentro de um determinado intervalo de tempo no passado. |
Correção rápida não suportada. |
Não |
|
Backup de dados e snapshots |
O backup de log não está ativado para a instância AnalyticDB for MySQL |
Um cluster AnalyticDB for MySQL é considerado não compatível se o backup de log não estiver ativado. |
Esta correção ativa o backup de log para o cluster AnalyticDB for MySQL selecionado, com um período de retenção padrão de 7 dias. |
Não |
|
Backup de dados e snapshots |
Nenhum conjunto de backup de dados disponível para a instância AnalyticDB for PostgreSQL (Novidade no Modelo 3.0) |
A verificação de backup de dados para AnalyticDB for PostgreSQL visa garantir que a instância tenha um conjunto de backup disponível para prevenir interrupções nos negócios causadas por perda de dados ou operação incorreta. Verificando periodicamente a política de backup e o status do backup, é possível melhorar efetivamente a segurança dos dados e as capacidades de recuperação. Uma instância de armazenamento AnalyticDB for PostgreSQL em execução e não Serverless é considerada não compatível se não tiver nenhum conjunto de backup de dados disponível dentro de um número especificado de horas no passado (o padrão é 7 dias ou 168 horas). |
Após a ativação, a instância AnalyticDB for PostgreSQL realiza backup de dados de acordo com a configuração de backup, gerando um conjunto de backup disponível. O AnalyticDB for PostgreSQL pode restaurar uma nova instância para um ponto histórico no tempo através de um backup básico completo e backups contínuos de logs, garantindo a segurança dos dados naquele momento. |
Não |
|
Backup de dados e snapshots |
A proteção de backup de dados para a instância ECS está em risco (Novidade no Modelo 3.0) |
Diferentes soluções de snapshot e backup devem ser selecionadas para diferentes cenários, como proteção diária de dados, acompanhamento de operações de alto risco, proteção regional contra desastres e recuperação completa da máquina. Caso contrário, pode ser impossível recuperar dados, e uma solução de backup incompleta também faz com que a recuperabilidade e eficiência de arquivos essenciais não atendam às expectativas. Uma instância ECS é considerada não compatível se não tiver ativado nenhuma das seguintes soluções de backup: 1. Ativar solução de snapshot de disco em nuvem. 2. Configurar solução de backup "Backup de Arquivo/Banco de Dados Autogerenciado". |
Correção rápida não suportada. |
Não |
|
Backup de dados e snapshots |
Nenhuma política de snapshot automático definida para o disco ECS |
Um disco ECS é considerado não compatível se uma política de snapshot automático não estiver definida para ele. |
Esta correção ativa a política de snapshot especificada para a instância de disco ECS selecionada. Como as políticas de snapshot são independentes em cada região, se existir uma política com o mesmo nome na região onde o disco selecionado está localizado, a política existente será usada. Caso contrário, uma nova política de snapshot será criada. |
Não |
|
Backup de dados e snapshots |
O backup de log não está ativado para a instância MongoDB |
Uma instância MongoDB é considerada não compatível se o backup de log não estiver ativado. |
Esta correção ativa o backup de log para o cluster MongoDB selecionado, com um período de retenção padrão de 7 dias. |
Não |
|
Backup de dados e snapshots |
A política de backup de dados para o sistema de arquivos NAS está em risco (Novidade no Modelo 3.0) |
Se a lixeira do NAS e o Cloud Backup não estiverem ativados, você não poderá recuperar arquivos excluídos ou adulterados acidentalmente em tempo hábil. Se a replicação entre regiões não estiver ativada para o cofre de backup, a georredundância multiversão não pode ser alcançada, e os dados não podem ser restaurados em um local diferente, afetando gravemente a continuidade dos negócios. Um sistema de arquivos NAS é considerado não compatível se não tiver ativado nenhuma das seguintes soluções de backup: 1. Ativar lixeira do NAS. 2. Ativar backup do NAS. |
Esta correção ativa o recurso de lixeira do NAS. Para evitar interrupção dos negócios ou perda permanente de dados causada pela exclusão acidental de arquivos em um sistema de arquivos NAS de Uso Geral, recomendamos ativar o recurso de lixeira. Após a ativação, arquivos ou diretórios excluídos são armazenados temporariamente na lixeira e são excluídos permanentemente após o período de retenção especificado. Você pode restaurar esses arquivos e suas informações de metadados, como UID, GID e ACL, durante o período de retenção. |
Não |
|
Backup de dados e snapshots |
A política de backup de dados para o bucket OSS está em risco |
Os dados no nível do bucket devem ser protegidos. Se o versionamento não estiver ativado, versões históricas de operações de sobrescrita e exclusão de dados podem não ser salvas. Se ocorrer um problema, é impossível restaurar o Objeto armazenado no bucket para um ponto específico no tempo. Simultaneamente, se a replicação entre regiões não estiver ativada, operações sob a mesma conta ou contas diferentes não são sincronizadas para outra região. Quando ocorre um desastre ou falha, isso prejudica gravemente a continuidade dos negócios. Um bucket OSS é considerado não compatível se não tiver pelo menos uma das seguintes soluções de backup ativadas: 1. Ativar versionamento do OSS. 2. Ativar backup de bucket OSS. |
Esta correção ativa o versionamento para a instância OSS selecionada. Após a ativação do versionamento, operações de sobrescrita e exclusão de dados são salvas como versões históricas. Se você sobrescrever ou excluir acidentalmente um Objeto, poderá restaurar o Objeto armazenado no bucket para qualquer versão histórica a qualquer momento. |
Não |
|
Backup de dados e snapshots |
O backup de nível 2 não está ativado para o cluster PolarDB |
Um cluster PolarDB é considerado não compatível se o backup de nível 2 não estiver ativado e o período de retenção for maior ou igual a 30. |
Esta correção define o ciclo de backup de nível 2 e o período de retenção do backup de nível 2 (padrão é 30 dias) para o cluster PolarDB selecionado. Se o backup de nível 2 não estiver atualmente ativado, ele será ativado automaticamente. |
Não |
|
Backup de dados e snapshots |
O backup de log não está ativado para a instância RDS |
Uma instância RDS é considerada não compatível se o backup de log não estiver ativado. |
Esta correção ativa o backup de log para a instância RDS selecionada, com um período de retenção padrão de 7 dias. |
Não |
|
Backup de dados e snapshots |
A política de backup de dados para a instância Tablestore está em risco (Novidade no Modelo 3.0) |
Se o backup do Tablestore e o backup entre regiões não estiverem ativados, dados importantes não podem ser restaurados rapidamente de maneira simples, eficiente, segura e confiável. Uma vez que ocorra uma falha, a continuidade dos negócios é seriamente afetada. Uma instância Tablestore é considerada não compatível se uma solução de backup não estiver ativada. |
Correção rápida não suportada. |
Não |
|
Backup de dados e snapshots |
O pod da instância elástica ECI não tem volume de dados montado |
Um pod de instância elástica ECI é considerado não compatível se não tiver nenhum volume de dados montado. |
Correção rápida não suportada. |
Não |
|
Backup de dados e snapshots |
O backup automático não está ativado para a instância Elasticsearch |
Uma instância Elasticsearch é considerada não compatível se o backup automático não estiver ativado. |
Realizar esta operação ativa o recurso de backup automático para a instância Elasticsearch selecionada. O sistema faz backup automático dos dados de acordo com o ciclo e horário definidos. Se os dados forem excluídos acidentalmente ou houver um erro lógico na aplicação, você pode usar o recurso de recuperação de backup automático para restaurar os dados de backup de um ponto específico no tempo para a instância ES original, garantindo a segurança dos dados. Observe que os backups automáticos retêm dados de snapshot apenas pelos últimos 7 dias, e os dados de backup automático só podem ser usados para restaurar o cluster original. |
Não |
|
Backup de dados e snapshots |
O backup incremental não está definido para a instância Redis |
Uma instância Redis (Tair Enterprise Edition) é considerada não compatível se o backup incremental não estiver ativado. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O cluster ACK apresenta risco de implantação em zona única |
Usar um cluster regional permite alcançar capacidades de recuperação de desastres entre regiões. Um cluster ACK é compatível se for um cluster regional com nós distribuídos em 3 ou mais zonas. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância ALB apresenta risco de implantação em zona única |
Se apenas uma zona for selecionada, isso afeta a instância ALB quando essa zona falhar, impactando a estabilidade do negócio. Uma instância ALB é compatível se for uma instância multizona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
Os recursos montados no grupo de servidores ALB estão todos em uma única zona |
Adicionar recursos de múltiplas zonas a um grupo de servidores de balanceador de carga ALB garante que, mesmo se uma zona falhar, a aplicação ainda possa rodar em outras zonas, proporcionando melhor tolerância a falhas. Um grupo de servidores de balanceador de carga ALB é compatível se os recursos montados nele estiverem distribuídos por várias zonas. Esta regra não se aplica se o grupo de servidores ALB não tiver recursos montados ou se o grupo de servidores for do tipo IP ou Function Compute. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância API Gateway apresenta risco de implantação em zona única |
Recomendamos usar uma instância API Gateway multizona, que possui capacidades de recuperação de desastres multizona. Uma instância de gateway é compatível se for multizona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A distribuição de instâncias ECS dentro de uma região é desequilibrada entre as zonas (Novidade no Modelo 3.0) |
Implantar todas as instâncias ECS na mesma zona representa um risco de ponto único de falha. Quando essa zona falha devido a danos de hardware, interrupção de rede ou outros problemas, todas as instâncias ECS naquela região ficam indisponíveis simultaneamente, levando à interrupção dos negócios. Uma conta é considerada não compatível se todas as instâncias ECS na mesma região estiverem implantadas na mesma zona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância Flink não usa um tipo de CU entre zonas |
Recomendamos ativar a opção entre zonas para CUs do Flink, o que fornece capacidades de recuperação de desastres multizona. Uma instância Flink é considerada não compatível se não usar uma CU multizona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância GWLB apresenta risco de implantação em zona única |
Recomendamos ativar a opção multizona para instâncias GWLB, o que fornece capacidades de recuperação de desastres multizona. Uma instância Gateway Load Balancer é considerada não compatível se não for multizona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
Os recursos montados no grupo de servidores GWLB estão todos em uma única zona (Novidade no Modelo 3.0) |
Montar recursos em um grupo de servidores multizona pode melhorar as capacidades de recuperação de desastres do sistema e reduzir o risco de interrupção dos negócios. Uma conta é considerada não compatível se uma instância GWLB for de zona única, ou se um grupo de servidores usado por um listener sob uma instância GWLB não tiver recursos de múltiplas zonas adicionados. Esta regra não se aplica quando não há recursos no grupo de servidores ou o tipo de recurso é IP. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
Componentes relacionados ao MSE apresentam risco de implantação em zona única |
Recomendamos adotar uma arquitetura de implantação multizona para componentes relacionados ao MSE para melhorar sua estabilidade. Um componente relacionado ao MSE é considerado não compatível se estiver implantado em uma única zona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O gateway MSE apresenta risco de implantação em zona única |
Todas as réplicas de instância do gateway atual estão implantadas na mesma zona (AZ). Esta forma de implantação não possui capacidades de alta disponibilidade, e seu negócio pode ser prejudicado em casos extremos. Atualize para a nova versão o mais rápido possível para dispersar as instâncias do gateway em múltiplas zonas. Um componente de gateway MSE Ingress é considerado não compatível se tiver uma arquitetura de zona única. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância MongoDB apresenta risco de implantação em zona única |
Usar uma instância MongoDB que não seja multizona é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância NLB apresenta risco de implantação em zona única |
Para instâncias Network Load Balancer, é fortemente recomendado configurar multizona para atender à recuperação de desastres multizona. Usar uma instância Network Load Balancer de zona única é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
Os recursos montados no grupo de servidores NLB estão todos em uma única zona |
Recomendamos adicionar recursos de múltiplas zonas a um grupo de servidores Network Load Balancer, o que fornece capacidades de recuperação de desastres multizona. Um grupo de servidores Network Load Balancer é compatível se seus recursos estiverem distribuídos por várias zonas. Isso não se aplica se não houver recursos no grupo de servidores ou se o tipo de recurso for IP. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O armazenamento com redundância de zona não está ativado para o bucket OSS |
Um bucket OSS é considerado não compatível se o armazenamento com redundância de zona não estiver ativado. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O cluster de armazenamento hot standby não está ativado para o cluster PolarDB |
Um cluster PolarDB é considerado não compatível se um cluster de armazenamento hot standby não estiver ativado e os dados estiverem distribuídos em uma única zona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O serviço de endpoint PrivateLink apresenta risco de implantação em zona única |
Configurar múltiplas zonas para um serviço de endpoint pode reduzir significativamente o risco de interrupção do serviço, distribuir o tráfego de forma mais uniforme para evitar sobrecarga em uma única zona e fornecer acesso mais próximo, o que reduz a latência da rede e melhora a velocidade de acesso. Configurar múltiplas zonas para um serviço de endpoint é compatível. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância RDS apresenta risco de implantação em zona única |
Usar uma instância RDS que não seja multizona é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância Redis apresenta risco de implantação em zona única |
Usar uma instância Redis que não seja multizona é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância SLB e o grupo de servidores do seu listener apresentam risco de ponto único de implantação |
Uma conta é considerada não compatível se uma instância SLB for de zona única, ou se um grupo de servidores usado por um listener sob uma instância SLB não tiver recursos de múltiplas zonas adicionados. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância ApsaraMQ for Kafka apresenta risco de implantação em zona única |
Quando você estiver usando uma instância da Edição Profissional e tiver selecionado apenas implantação em zona única durante a implantação, poderá atualizar o cluster para uma arquitetura de implantação multizona editando a zona secundária, o que aprimora as capacidades de recuperação de desastres do cluster. Uma instância ApsaraMQ for Kafka é compatível se for multizona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O roteador de trânsito apresenta risco de implantação em zona única |
Para roteadores de trânsito existentes, é fortemente recomendado configurar multizona para atender às capacidades de recuperação de desastres multizona. Um roteador de trânsito é considerado não compatível se sua conexão VPC configurar apenas um vSwitch em uma zona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância AnalyticDB for PostgreSQL apresenta risco de implantação em zona única |
Recomendamos ativar a recuperação de desastres entre zonas para instâncias AnalyticDB for PostgreSQL. Quando a zona primária falha, o sistema troca automaticamente o nó da zona secundária para o nó primário para continuar fornecendo serviços e garantir a continuidade dos negócios. Uma instância AnalyticDB for PostgreSQL é considerada não compatível se não tiver a recuperação de desastres entre zonas ativada. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O cluster ClickHouse apresenta risco de implantação em zona única |
Recomendamos usar uma instância de cluster ClickHouse multizona, que possui capacidades de recuperação de desastres multizona. Uma instância de cluster ClickHouse multizona é compatível. Atualmente, apenas a versão community é verificada quanto à arquitetura multizona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância HBase apresenta risco de implantação em zona única |
Recomendamos adotar uma arquitetura de implantação multizona, que possui maiores capacidades de recuperação de desastres. Uma instância HBase é considerada não compatível se não adotar uma implantação multizona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância Lindorm apresenta risco de implantação em zona única |
Recomendamos implantar instâncias Lindorm em múltiplas zonas. Instâncias multizona possuem maiores capacidades de recuperação de desastres. Simultaneamente, instâncias Lindorm podem alcançar forte consistência de dados entre múltiplas zonas, e também podem retornar o resultado mais rápido sob consistência eventual de dados, o que melhora a qualidade de serviço dos negócios online. Uma instância Lindorm é considerada não compatível se não adotar uma implantação multizona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância PolarDB-X 2.0 apresenta risco de implantação em zona única |
Recomendamos usar uma instância PolarDB-X 2.0 multizona, que possui capacidades de recuperação de desastres multizona. Uma instância PolarDB-X 2.0 com arquitetura multizona é compatível. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância Tablestore apresenta risco de implantação em zona única |
Uma instância Tablestore é considerada não compatível se não usar uma implantação multizona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A inspeção do cluster ACK identifica que o CoreDNS tem apenas uma réplica (Novidade no Modelo 3.0) |
Se um CoreDNS de cluster ACK mantiver apenas uma configuração de réplica única, ele perde a alta disponibilidade. Quando o Pod falha, o serviço DNS é completamente interrompido, o que causa falha na resolução de nomes de domínio de serviço dentro do cluster e leva à interrupção da comunicação entre aplicações. Uma arquitetura de ponto único não tolera falhas de nós ou operações de manutenção. O serviço pode ser interrompido transitoriamente durante atualizações ou reinicializações, e o risco de operação de longo prazo é exacerbado. O número de réplicas deve ser expandido imediatamente para garantir redundância e estabilidade do serviço. Um cluster ACK é considerado não compatível se seu CoreDNS tiver apenas uma réplica. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O armazenamento com redundância de zona não está ativado para o bucket OSS associado ao ACR |
Recomendamos usar uma instância ACR Enterprise Edition e associá-la a um bucket OSS que tenha armazenamento com redundância de zona ativado. Um ACR é considerado não compatível se estiver associado a um bucket OSS com armazenamento localmente redundante. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O cluster ACS apresenta risco de implantação em zona única |
Recomendamos usar um cluster ACS regional multizona, que possui capacidades de recuperação de desastres multizona. Um cluster ACS é compatível se for um cluster regional com nós distribuídos em 3 ou mais zonas. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância Elasticsearch apresenta risco de implantação em zona única |
Usar uma instância Elasticsearch que não seja multizona é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O Projeto SLS não usa armazenamento com redundância de zona |
O Simple Log Service fornece dois tipos de redundância de armazenamento: armazenamento localmente redundante e armazenamento com redundância de zona. Estes cobrem mecanismos de redundância de dados de uma única zona a múltiplas zonas para garantir persistência e disponibilidade de dados. Um projeto de log é compatível se usar armazenamento com redundância de zona. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O VPN Gateway apresenta risco de implantação em zona única |
Para instâncias de túnel único existentes, é fortemente recomendado que você ative a alta disponibilidade de AZ no console e configure túneis duplos para conectar ao par. Um VPN é considerado não compatível se usar uma instância de túnel único. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O VPN Gateway não usa o modo de túnel duplo |
Uma conexão IPsec-VPN em modo de túnel duplo possui um túnel primário e um secundário. Se o túnel primário falhar, o tráfego pode ser transmitido através do túnel secundário, o que melhora a alta disponibilidade da conexão IPsec-VPN. Um VPN Gateway de túnel duplo é compatível se ambos os túneis primário e secundário estiverem conectados ao par. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
O Bastionhost apresenta risco de implantação em zona única |
Recomendamos usar a Edição Dual-Engine Enterprise ou a Edição Compatível com SM do Bastionhost para atender às capacidades de recuperação de desastres multizona. Usar a Edição Básica do Bastionhost é considerado não compatível. |
Correção rápida não suportada. |
Não |
|
Arquitetura multizona |
A instância ApsaraMQ for RocketMQ não usa a Edição Cluster de Alta Disponibilidade |
Recomendamos usar a Edição Cluster de Alta Disponibilidade, que possui capacidades de recuperação de desastres multizona. Uma instância ApsaraMQ for RocketMQ 5.0 é considerada não compatível se não for multizona. |
Correção rápida não suportada. |
Não |
|
Arquitetura de cluster |
O grupo de dimensionamento ESS está associado a apenas um único vSwitch |
Ao associar múltiplos vSwitches, um grupo de dimensionamento pode melhorar a robustez geral, confiabilidade e desempenho da aplicação, ajudando-a a atender melhor aos requisitos de negócio. Se um vSwitch estiver inacessível devido a problemas de rede ou outras condições, o tráfego do usuário ainda pode acessar a aplicação através de outros vSwitches. Um grupo de dimensionamento é compatível se estiver associado a pelo menos dois vSwitches. |
Correção rápida não suportada. |
Não |
|
Arquitetura de cluster |
Componentes relacionados ao MSE apresentam risco de ponto único de implantação |
Para o componente MSE ZooKeeper, recomendamos dimensionar para 3 ou mais nós. Para o componente Nacos-ANS, recomendamos dimensionar para 3 ou mais nós. Um componente relacionado ao MSE é considerado não compatível se estiver implantado em um único nó. |
Correção rápida não suportada. |
Não |
|
Arquitetura de cluster |
O gateway MSE apresenta risco de ponto único de implantação |
Uma instância de nó único apresenta um risco arquitetônico. Um ponto único de falha torna o serviço indisponível. Recomendamos dimensionar para 2 ou mais nós. Um componente MSE Ingress é considerado não compatível se estiver implantado em um único nó. |
Correção rápida não suportada. |
Não |
|
Arquitetura de cluster |
A instância PolarDB apresenta risco de ponto único de implantação |
Uma instância PolarDB é considerada não compatível se não usar a Edição Cluster ou a Edição Cluster Multi-master. |
Correção rápida não suportada. |
Não |
|
Arquitetura de cluster |
O failover automático primário/secundário não está ativado para a instância RDS (Novidade no Modelo 3.0) |
Quando o nó primário de uma instância está anormal e não pode ser usado, ou quando há um risco potencial na instância e um reparo de emergência foi realizado no nó secundário, o RDS aciona automaticamente um failover primário/secundário, trocando os nós primário e secundário. Após o failover, o endpoint da instância permanece inalterado, e a aplicação se conecta automaticamente ao novo nó primário (o antigo nó secundário), garantindo a alta disponibilidade da instância. Uma instância RDS é considerada não compatível se o recurso de failover automático primário/secundário não estiver ativado. |
Esta correção ativa o recurso de failover automático primário/secundário para a instância RDS. Quando o nó primário da instância está anormal e não pode ser usado, ou quando há um risco potencial na instância e um reparo de emergência foi realizado no nó secundário, o RDS aciona automaticamente um failover primário/secundário, trocando os nós primário e secundário. Após o failover, o endpoint da instância permanece inalterado, e a aplicação se conecta automaticamente ao novo nó primário (o antigo nó secundário), garantindo a alta disponibilidade da instância. |
Não |
|
Arquitetura de cluster |
Os nós primário e secundário do cluster RDS não estão configurados com o mesmo tamanho de instância (Novidade no Modelo 3.0) |
Se os nós primário e secundário de um cluster RDS não estiverem configurados com o mesmo tamanho de instância, pode impedir que o nó secundário assuma suavemente quando o nó primário falhar, levando a gargalos de desempenho ou interrupções de serviço. Além disso, especificações de instância diferentes podem levar a incompatibilidades de recursos, afetando a eficiência da sincronização de dados e a velocidade de recuperação, e reduzindo as capacidades de alta disponibilidade e recuperação de desastres do sistema. Detectar e garantir que os tamanhos das instâncias dos nós primário e secundário sejam consistentes ajuda a melhorar a estabilidade do sistema, aprimorar as capacidades de failover e garantir a continuidade dos negócios. Isso traz maior confiabilidade e controle de O&M para os clientes. Um cluster RDS é considerado não compatível se seus nós primário e secundário estiverem configurados com tamanhos de instância diferentes. |
Correção rápida não suportada. |
Não |
|
Arquitetura de cluster |
Os nós primário e secundário do cluster RDS não estão configurados com o mesmo tipo de instância (Novidade no Modelo 3.0) |
Se os nós primário e secundário de um cluster RDS não estiverem configurados com o mesmo tipo de instância, pode impedir que o nó secundário assuma suavemente quando o nó primário falhar, levando a gargalos de desempenho ou interrupções de serviço. Além disso, especificações de instância diferentes podem levar a incompatibilidades de recursos, afetando a eficiência da sincronização de dados e a velocidade de recuperação, e reduzindo as capacidades de alta disponibilidade e recuperação de desastres do sistema. Detectar e garantir que os tipos das instâncias dos nós primário e secundário sejam consistentes ajuda a melhorar a estabilidade do sistema, aprimorar as capacidades de failover e garantir a continuidade dos negócios. Isso traz maior confiabilidade e controle de O&M para os clientes. Um cluster RDS é considerado não compatível se seus nós primário e secundário estiverem configurados com tipos de instância diferentes. |
Correção rápida não suportada. |
Não |
|
Arquitetura de cluster |
O modo de alta confiabilidade não é usado para o Express Connect (Novidade no Modelo 3.0) |
Use o modo de alta confiabilidade do Express Connect para criar dois pontos de acesso na mesma região para alcançar redundância de rede, garantir a estabilidade e confiabilidade da transmissão de dados e atender aos requisitos de conformidade. Um circuito Express Connect é considerado não compatível se tiver menos de 2 pontos de acesso na mesma região. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Capacidade de armazenamento restante insuficiente para a instância RDS (Novidade no Modelo 3.0) |
Capacidade de armazenamento restante insuficiente para uma instância RDS pode levar a falhas de gravação no banco de dados, degradação de desempenho e até interrupções de serviço ou riscos de perda de dados. É necessário expandir a capacidade ou limpar dados em tempo hábil para evitar anomalias nos negócios, garantir a estabilidade do banco de dados e melhorar a confiabilidade e previsão de O&M. Uma instância RDS é considerada não compatível se tiver menos de 10% de sua capacidade de armazenamento restante por qualquer período de 1 hora dentro de 7 dias. |
Esta correção ativa o recurso de expansão automática de armazenamento para a instância RDS. Após a ativação, o espaço de armazenamento é expandido automaticamente quando atinge o limiar. A instância não precisa ser reiniciada durante a expansão, e não há impacto nos negócios. |
Não |
|
Cota e capacidade |
Chamadas de API ACK estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Chamadas de API ALB estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Chamadas de API CDN estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Chamadas de API ECS estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Chamadas de API NAS estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Chamadas de API PolarDB estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Chamadas de API RDS estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Chamadas de API Redis estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Chamadas de API RocketMQ estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Chamadas de API SLB estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Chamadas de API VPC estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Chamadas de API Cloud Enterprise Network (CEN) estão limitadas |
Chamadas de API são limitadas, o que leva a falhas nas chamadas e pode afetar a estabilidade do negócio. Uma conta é considerada não compatível se houver exceções de limitação para chamadas de API nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número total de clusters ACK está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número de clusters ACK atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número total de instâncias ALB está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número total de instâncias ALB atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número de atualizações de URL CDN está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número de atualizações de URL CDN atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número de nomes de domínio acelerados suportados pelo CDN está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número de nomes de domínio acelerados suportados pelo CDN atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número de atualizações de diretório CDN está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número de atualizações de diretório CDN atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número de itens de pré-busca CDN está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número de itens de pré-busca CDN atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número total de discos em nuvem EBS está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número total de discos em nuvem EBS atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para vCPUs de instâncias de assinatura ECS está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado a vCPUs de instâncias de assinatura ECS atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para vCPUs de instâncias spot ECS está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado a vCPUs de instâncias spot ECS atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para vCPUs de instâncias de pagamento conforme o uso ECS está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado à cota de vCPU de instâncias de pagamento conforme o uso ECS atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número total de EIPs está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número total de EIPs atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número total de grupos de dimensionamento ESS está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número total de grupos de dimensionamento ESS atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
Componentes relacionados ao MSE estão em risco de capacidade |
Garanta que a capacidade de recursos esteja dentro de um intervalo razoável. Se o limite de capacidade for excedido, pode levar a riscos de estabilidade. Um MSE é considerado não compatível se tiver uma métrica relacionada cuja capacidade seja excedida. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número de entradas SNAT que podem ser retidas em um NAT Gateway está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número de entradas SNAT que podem ser retidas em um NAT Gateway atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número de EIPs que podem ser vinculados a um NAT Gateway está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número de EIPs que podem ser vinculados a um NAT Gateway atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número total de instâncias NLB está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número total de instâncias NLB atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para instâncias RDS sob demanda está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado a instâncias RDS sob demanda atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número total de stacks ROS está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número total de stacks ROS atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número de listeners retidos por uma instância SLB está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número de listeners retidos por uma instância SLB atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número de servidores que podem ser montados no backend de uma instância SLB está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número de servidores que podem ser montados no backend de uma instância SLB atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número total de instâncias SLB está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número total de instâncias SLB atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número total de grupos de segurança está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número total de grupos de segurança atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número total de interfaces de rede elásticas está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número total de interfaces de rede elásticas (ENIs) atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Cota e capacidade |
O uso de cota para o número total de conjuntos de implantação está se aproximando do limite superior (Novidade no Modelo 3.0) |
Cota de recursos insuficiente pode restringir as operações de criação, alteração ou expansão de recursos do produto. Uma conta é considerada não compatível quando o item de cota relacionado ao número total de conjuntos de implantação atinge 80% de seu limite superior. |
Correção rápida não suportada. |
Não |
|
Gerenciamento de monitoramento |
Regras de alerta de monitoramento não estão definidas para recursos de produtos em nuvem |
Alcançar cobertura total de monitoramento de recursos é a base e a chave para garantir a continuidade dos negócios. Definir regras de alerta para recursos de produtos em nuvem é um meio necessário para alcançar o monitoramento desses recursos. Uma conta é considerada não compatível se houver recursos de produtos em nuvem que não estejam cobertos por nenhuma regra de alerta. |
Esta correção ativa automaticamente regras de alerta baseadas em melhores práticas para tipos de recursos em nuvem que não estão configurados com o Cloud Monitor. Por padrão, as notificações são enviadas para os destinatários de mensagens do tipo "Contato de Alerta da Conta Alibaba Cloud". Confirme as configurações estão corretas. Após a ativação, você pode visualizar o status ativado ou atualizar os parâmetros de alerta no recurso de alerta com um clique do Cloud Monitor. |
Não |
|
Gerenciamento de monitoramento |
Regras de alerta de alta prioridade não estão configuradas no ARMS |
Configurar regras de alerta eficazes garante que você seja notificado em tempo hábil quando o sistema de negócios não atender às condições operacionais esperadas, permitindo uma resposta de emergência oportuna. Uma conta é considerada não compatível se nenhuma regra de alerta de nível P1 estiver configurada para monitoramento de aplicações ou monitoramento Prometheus no Alibaba Cloud ARMS, ou se nenhuma política de notificação correspondente estiver configurada. |
Correção rápida não suportada. |
Não |
|
Gerenciamento de monitoramento |
Alertas de alta prioridade no ARMS não são tratados prontamente |
A métrica MTTx (Tempo médio para xx, como MTTR: Tempo Médio de Recuperação) pode ser usada como uma medida importante da eficiência no tratamento de alertas. Responder prontamente a alertas de alta prioridade pode melhorar efetivamente a eficiência de recuperação de alertas e até de falhas, o que melhora a qualidade de serviço do sistema de negócios. Uma conta é considerada não compatível se nenhuma regra de alerta de nível P1 estiver configurada para monitoramento de aplicações ou monitoramento Prometheus, ou se houver alertas no Alibaba Cloud ARMS que não foram resolvidos dentro de 30 minutos (pendentes de reivindicação, em andamento ou resolvidos após mais de 30 minutos). |
Correção rápida não suportada. |
Não |
|
Gerenciamento de monitoramento |
Regras de alerta com alertas contínuos não são tratadas prontamente |
Regras de alerta que permanecem continuamente em estado de alerta por um longo período são um problema que requer atenção e governança. Normalmente, o problema precisa ser resolvido o mais rápido possível para restaurar a métrica de monitoramento a um nível normal, ou as regras de alerta precisam ser ajustadas com base na situação real para evitar excesso de mensagens de alerta ou fadiga de alerta que interfiram no trabalho normal de monitoramento e O&M. Uma conta é considerada não compatível se qualquer regra de alerta definida no Cloud Monitor estiver continuamente em estado de alerta por mais de 24 horas. |
Correção rápida não suportada. |
Não |
|
Gerenciamento de monitoramento |
O monitoramento Prometheus não está configurado para o cluster ACK |
Conectar um cluster ACK ao monitoramento ajuda as equipes de desenvolvimento e O&M a visualizar o status de execução do sistema, incluindo a camada de infraestrutura, a camada de desempenho de contêineres e muito mais. Um cluster ACK é considerado não compatível se "Ativar Monitoramento Prometheus Alibaba Cloud" não estiver configurado. |
Correção rápida não suportada. |
Não |
|
Gerenciamento de monitoramento |
O monitoramento de aplicações não está configurado para o cluster ACK |
Para aplicações distribuídas e baseadas em microsserviços, você pode conectar ao Monitoramento de Aplicações ARMS para rastreamento de link completo e monitoramento de desempenho em tempo real no nível de código, ajudando a equipe de O&M a acompanhar a saúde da aplicação a todo momento. Uma aplicação é considerada não compatível se estiver implantada no ACK ou ECS, mas não conectada ao Monitoramento de Aplicações ARMS. |
Correção rápida não suportada. |
Não |
|
Gerenciamento de monitoramento |
Recomenda-se monitoramento unificado de recursos entre contas Alibaba Cloud para ARMS |
Ao criar uma instância de agregação global, você pode alcançar monitoramento unificado entre contas. Uma conta é considerada não compatível se não estiver usando ARMS e não tiver criado uma instância GlobalView. |
Correção rápida não suportada. |
Não |
Custo
|
Categoria |
Item de verificação |
Descrição do item de verificação |
Descrição da correção rápida |
Suporta tomada de decisão assistida |
|
Monitoramento de custos |
Alerta de crédito disponível não está ativado para a conta (Novidade no Modelo 3.0) |
Se o "Available Credit Alert" não estiver ativado para a conta no User Center, isso pode gerar riscos como suspensão de serviço por pagamentos atrasados, perda de dados ou interrupções nos negócios quando o saldo da conta se esgotar. Além disso, a falta de um mecanismo de alerta também pode causar estouro de orçamento, afetando a gestão orçamentária empresarial e a conformidade financeira. Caso o "Available Credit Alert" não esteja habilitado para a conta no User Center, a configuração é considerada não conforme. |
Esta correção ativará o recurso de alerta de crédito disponível. Quando o crédito disponível da sua conta ficar abaixo do limiar de alerta, você será notificado por mensagem de texto, e-mail e mensagem interna para o contato da conta (com lembretes por até 5 dias consecutivos). |
Não |
|
Otimização do método de faturamento |
Recomenda-se usar faturamento por assinatura ou adicionar recursos de pagamento conforme o uso a um plano de economia para instâncias ECS |
Para recursos utilizados de forma estável por longos períodos, recomenda-se o método de faturamento por assinatura. Geralmente, o custo de uma instância ECS com faturamento por assinatura é menor do que com pagamento conforme o uso. Um plano de economia oferece descontos maiores sobre o modelo pay-as-you-go em troca do compromisso de utilizar uma quantidade estável de recursos durante um determinado período. Se uma instância ECS utilizar o método de pagamento conforme o uso e não tiver adquirido uma instância de plano de economia, essa prática não é considerada ideal. |
Correção rápida não suportada. |
Não |
|
Otimização do método de faturamento |
Recomenda-se usar faturamento por assinatura para instâncias RDS |
Recursos usados de maneira contínua e estável devem preferencialmente adotar o faturamento por assinatura. Normalmente, o custo de uma instância RDS nesse modelo é inferior ao do pagamento conforme o uso. Instâncias RDS configuradas como pay-as-you-go são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Site ESA está em estado anormal |
Este item garante que o site esteja ativo para que o ESA possa fornecer aceleração e proteção adequadas. A ausência dessa ativação indica que as melhores práticas de otimização de recursos de aplicação não estão sendo seguidas. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Baixa utilização de recursos em instância ECS |
Manter a utilização de recursos das instâncias ECS em níveis razoáveis ao longo do tempo é fundamental para a gestão de custos na nuvem. A plataforma oferece diversas especificações de instâncias ECS, e as empresas precisam escolher aquelas adequadas aos ciclos reais de seus negócios para controlar despesas. Se tanto o uso de CPU quanto o de memória de uma instância ECS permanecerem abaixo de 3% por 30 dias consecutivos, a configuração não atende às melhores práticas. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Baixa utilização de disco ECS |
A manutenção da utilização de recursos das instâncias ECS em patamares adequados é essencial para o gerenciamento financeiro na nuvem. Como a plataforma disponibiliza várias especificações, cabe à empresa selecionar a mais apropriada conforme a demanda cíclica do negócio. Utilização de disco ECS inferior a 3% durante 30 dias seguidos caracteriza descumprimento das melhores práticas. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Baixa utilização de recursos em instância RDS |
Controlar o uso de recursos das instâncias RDS em níveis saudáveis é uma tarefa importante para a eficiência de custos. A plataforma fornece múltiplas especificações, exigindo que as organizações escolham opções compatíveis com seus padrões de carga. Quando CPU, memória e disco de uma instância RDS ficam todos abaixo de 3% por 30 dias consecutivos, considera-se que as melhores práticas não foram aplicadas. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Baixa utilização de disco RDS |
Garantir que os recursos das instâncias RDS sejam aproveitados adequadamente ajuda a evitar desperdícios financeiros. Dada a variedade de especificações disponíveis, é necessário alinhar a escolha da instância à realidade operacional da empresa. Uso de disco RDS abaixo de 3% por 30 dias contínuos indica desvio das melhores práticas. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Existência de instância ALB ociosa |
Um balanceador de carga ALB que possua um listener sem servidores backend adicionados e tenha sido criado há mais de 7 dias é classificado como não conforme. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Existência de instância ECS ociosa |
Instâncias ECS paradas que não possuem o modo de não cobrança para instâncias interrompidas configurado são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Existência de disco ECS ocioso |
Discos de nuvem que não estão em uso e foram criados há mais de 7 dias são tratados como não conformes. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Existência de instância EIP ociosa |
Endereços EIP não vinculados a nenhuma instância de recurso e criados há mais de 7 dias são considerados não conformes. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Existência de instância de sistema de arquivos NAS ociosa |
Sistemas de arquivos NAS sem destino de montagem adicionado e criados há mais de 7 dias são classificados como não conformes. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Existência de NAT Gateway ocioso |
Um NAT Gateway não vinculado a um EIP, ou cujo EIP vinculado não tenha entradas SNAT/DNAT definidas, e criado há mais de 7 dias, é considerado não conforme. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Existência de instância SLB ociosa |
Balanceadores de carga SLB sem nenhum listener em execução e criados há mais de 7 dias são considerados não conformes. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Existência de instância VPC NAT Gateway ociosa |
Um VPC NAT Gateway que não esteja vinculado a um EIP, ou cujo EIP associado não possua entradas SNAT/DNAT configuradas, e tenha sido criado há mais de 7 dias, é tratado como não conforme. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Existência de VPN Gateway ocioso |
Um VPN Gateway sem política de rota baseada em destino configurada ou sem propagação automática de rotas BGP ativada, e criado há mais de 7 dias, é considerado não conforme. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Existência de instância de largura de banda compartilhada ociosa |
Instâncias de largura de banda compartilhada não vinculadas a recursos e criadas há mais de 7 dias são classificadas como não conformes. |
Correção rápida não suportada. |
Não |
|
Otimização de recursos de aplicação |
Existência de instância de imagem de contêiner ociosa |
Instâncias de imagem de contêiner sem namespace ou repositório de imagens criado, e que existam há mais de 7 dias, são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Política de custos |
Conjunto de gerenciamento de custos não está ativado para cluster ACK |
Métodos tradicionais carecem de visibilidade e controle eficazes de custos para cenários nativos da nuvem. O conjunto de gerenciamento de custos oferece funcionalidades como inspeção de desperdício de recursos e previsão de gastos. Clusters ACK sem esse recurso ativado não seguem as melhores práticas. |
Correção rápida não suportada. |
Não |
Eficiência
|
Categoria |
Item de verificação |
Descrição do item de verificação |
Descrição da correção rápida |
Suporta tomada de decisão assistida |
|
Gerenciamento de Recursos |
Recursos associados estão divididos em diferentes grupos de recursos |
Quando recursos relacionados não são consolidados em um único grupo de recursos, a gestão de permissões, finanças e operações baseada em grupos deixa de abranger todos os ativos-alvo. Uma conta é considerada não conforme se houver recursos associados fora do mesmo grupo de recursos personalizado. |
Correção rápida não suportada. |
Não |
|
Gerenciamento de Recursos |
Tags personalizadas não são usadas para etiquetar recursos |
As tags personalizadas permitem identificar, classificar e organizar recursos com maior flexibilidade. Contas em que menos de 75% dos recursos possuem tags personalizadas são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Gerenciamento de Recursos |
Grupos de recursos personalizados não são usados para agrupar recursos |
O uso de grupos de recursos personalizados proporciona controle mais flexível sobre o acesso e a utilização dos ativos. Se a proporção de recursos pertencentes a grupos personalizados for inferior a 75% do total, a conta é classificada como não conforme. |
Correção rápida não suportada. |
Não |
|
Gerenciamento de Recursos |
Tags predefinidas não são utilizadas |
Tags predefinidas são criadas antecipadamente e aplicáveis a todas as regiões, facilitando a vinculação e a gestão de recursos durante a fase de implementação. Contas com proporção de tags predefinidas em relação às personalizadas abaixo de 80% são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Gerenciamento de Recursos |
Tags de criador não estão ativadas |
À medida que a escala de recursos na nuvem cresce, múltiplas pessoas passam a gerenciá-los. Em contextos de custo e segurança, identificar os criadores dos recursos é essencial para alocação financeira, rastreabilidade e eficiência operacional. Contas sem tags de criador ativadas são consideradas não conformes. |
Uma tag de criador é uma tag de sistema gerada e vinculada automaticamente pela Alibaba Cloud ao recurso correspondente para identificar quem o criou. Essas tags ajudam na análise de custos e faturas, permitindo uma gestão financeira mais eficaz. Esta correção ativa as tags de criador para a conta atual. |
Não |
|
Gerenciamento de Recursos |
Recomenda-se ativar o recurso de pesquisa de recursos multiconta |
Ao utilizar um diretório de recursos para gerenciar várias contas Alibaba Cloud, a conta de gerenciamento ou a conta de administrador delegado podem visualizar e pesquisar recursos de todos os membros do diretório. Contas sem a pesquisa de recursos entre contas ativada são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Sistema de contas |
Conta não é gerenciada por um diretório de recursos |
Comparado à gestão descentralizada, o gerenciamento unificado de múltiplas contas traz benefícios em termos de permissões, segurança e custos. Contas que não pertencem a nenhum diretório de recursos são classificadas como não conformes. |
Correção rápida não suportada. |
Não |
|
Sistema de contas |
Recomenda-se a gestão centralizada de contatos de mensagens multiconta |
O recurso de gerenciamento de contatos de mensagens do diretório de recursos permite centralizar os contatos de notificação entre contas. Uma conta é considerada não conforme se nenhum contato de mensagens do diretório for detectado ou se ele não estiver vinculado a um diretório, pasta de recursos ou membro. |
Correção rápida não suportada. |
Não |
|
Sistema de contas |
Recomenda-se definir uma conta de administrador delegado para o diretório de recursos onde a conta está localizada |
O uso de uma conta de administrador delegado separa tarefas de gestão organizacional das atividades operacionais de negócios. A conta de gerenciamento cuida da organização do diretório, enquanto a conta delegada executa funções de negócios nos serviços confiáveis. Contas sem administrador delegado definido nos serviços confiáveis habilitados pela conta de gerenciamento (MA) do diretório são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API ACK obsoleta |
APIs ACK obsoletas não recebem mais manutenção, apresentam riscos de estabilidade e não suportam novos recursos. Contas que chamaram alguma API ACK obsoleta nos últimos 30 dias são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API ALB obsoleta |
APIs ALB descontinuadas deixam de ser mantidas, trazem riscos de estabilidade e impedem o uso de novas funcionalidades. Chamadas a essas APIs nos últimos 30 dias tornam a conta não conforme. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API CDN obsoleta |
APIs CDN obsoletas não são mais mantidas, possuem riscos de estabilidade e não oferecem suporte a novos recursos. A conta é considerada não conforme se houver chamadas a essas APIs nos últimos 30 dias. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API CEN obsoleta |
APIs CEN descontinuadas perdem manutenção, apresentam instabilidade potencial e não aceitam novas features. Contas com chamadas recentes (últimos 30 dias) a essas APIs são classificadas como não conformes. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API ECS obsoleta |
APIs ECS obsoletas não recebem suporte, têm riscos de estabilidade e não permitem acesso a novos recursos. Uso dessas APIs nos últimos 30 dias resulta em não conformidade da conta. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API NAS obsoleta |
APIs NAS descontinuadas perdem manutenção, apresentam riscos operacionais e não suportam inovações. Contas que as utilizaram nos últimos 30 dias são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API PolarDB obsoleta |
APIs PolarDB obsoletas não são mantidas, trazem riscos de estabilidade e bloqueiam novos recursos. Chamadas nos últimos 30 dias caracterizam não conformidade. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API RDS obsoleta |
APIs RDS descontinuadas perdem suporte, apresentam instabilidade e não incluem novas funcionalidades. Contas com chamadas recentes a essas APIs são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API Redis obsoleta |
APIs Redis obsoletas não recebem manutenção, possuem riscos de estabilidade e não suportam novos recursos. Uso nos últimos 30 dias torna a conta não conforme. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API RocketMQ obsoleta |
APIs RocketMQ descontinuadas perdem suporte, apresentam riscos operacionais e não permitem novas features. Contas que as chamaram nos últimos 30 dias são classificadas como não conformes. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API SLB obsoleta |
APIs SLB obsoletas não são mantidas, trazem riscos de estabilidade e não oferecem novos recursos. Chamadas recentes (últimos 30 dias) resultam em não conformidade. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Usuário chama uma API VPC obsoleta |
APIs VPC descontinuadas perdem manutenção, apresentam instabilidade e não suportam inovações. Contas com uso dessas APIs nos últimos 30 dias são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Recomenda-se usar métodos automatizados para gerenciamento contínuo de recursos |
Uma conta é considerada não conforme se a taxa de chamadas OpenAPI para gerenciar recursos continuamente via métodos fora do console não atingir 100% nos últimos 30 dias. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Recomenda-se usar métodos automatizados para provisionamento diário de recursos |
Contas cuja proporção de chamadas OpenAPI para criar recursos via métodos não-console no último ano não alcançar 100% são classificadas como não conformes. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Recomenda-se usar métodos automatizados para gerenciar recursos |
Se a taxa de chamadas OpenAPI realizadas por meios automatizados (SDK, Terraform, Cloud Control API, CADT, ROS e Service Catalog) nos últimos 30 dias não atingir 100%, a conta é considerada não conforme. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Taxa de sucesso da interface de criação de recursos não atingiu 100% |
Contas com taxa de sucesso inferior a 100% na criação de recursos de infraestrutura via métodos automatizados (OpenAPI, Cloud Control API, SDK ou Terraform) nos últimos 30 dias são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Provisionamento e orquestração de recursos |
Taxa de sucesso da interface de alteração de recursos não atingiu 100% |
Se a taxa de sucesso na modificação de recursos de infraestrutura usando automação (OpenAPI, Cloud Control API, SDK ou Terraform) nos últimos 30 dias for menor que 100%, a conta é classificada como não conforme. |
Correção rápida não suportada. |
Não |
Desempenho
|
Categoria |
Item de verificação |
Descrição do item de verificação |
Descrição da correção rápida |
Suporta tomada de decisão assistida |
|
Monitoramento de desempenho |
EIP associado ao ALB apresenta risco de alta carga de desempenho (Novidade no Modelo 3.0) |
Quando o uso de largura de banda de saída de um EIP associado a uma instância ALB permanece elevado por muito tempo, ocorre degradação de desempenho, redução de estabilidade e possíveis interrupções de serviço. Recomenda-se atenção e tratamento imediatos. Uma instância ALB é considerada não conforme se o uso máximo de largura de banda de saída de qualquer EIP associado for igual ou superior a 80% por pelo menos 8 horas nas últimas 24 horas. |
Correção rápida não suportada. |
Não |
|
Monitoramento de desempenho |
Largura de banda compartilhada associada ao ALB apresenta risco de alta carga de desempenho (Novidade no Modelo 3.0) |
Uso prolongado e excessivo da largura de banda de saída em uma instância de largura de banda compartilhada vinculada a um ALB causa degradação de desempenho, instabilidade e possíveis falhas de serviço. É importante monitorar e agir rapidamente. Instâncias ALB são consideradas não conformes se o pico de uso de largura de banda de saída da largura de banda compartilhada associada atingir ou ultrapassar 80% por pelo menos 8 horas nas últimas 24 horas. |
Correção rápida não suportada. |
Não |
|
Monitoramento de desempenho |
Disco de nuvem EBS apresenta risco de desempenho devido a alto throughput |
Esta verificação ajuda a prevenir gargalos, avaliar a alocação adequada de armazenamento e determinar a necessidade de expansão para garantir a continuidade dos negócios. Um disco EBS é considerado não conforme se seu uso de IOPS ou BPS nas últimas 24 horas exceder 90% da capacidade do tipo de disco. |
Correção rápida não suportada. |
Não |
|
Monitoramento de desempenho |
Disco de nuvem EBS apresenta risco de desempenho devido a alto uso de espaço |
Utilização excessiva de espaço em disco aumenta o risco de perda de dados. Este item auxilia na identificação precoce de gargalos e na prevenção de degradação de desempenho. Discos EBS com uso de espaço superior a 80% são classificados como não conformes. |
Correção rápida não suportada. |
Não |
|
Monitoramento de desempenho |
Instância ECS apresenta risco de desempenho devido a alto uso de CPU |
Manter o uso de CPU do ECS em níveis saudáveis é fundamental para a estabilidade e operação contínua dos negócios. Cargas elevadas retardam respostas e podem acionar mecanismos de proteção automática, como reinicializações ou degradação de serviço. Instâncias ECS com uso de CPU acima de 85% por mais de 8 horas acumuladas nas últimas 24 horas são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Monitoramento de desempenho |
Instância ECS apresenta risco de desempenho devido a alto uso de memória |
Garantir níveis adequados de uso de memória no ECS evita degradação de desempenho e interrupções por insuficiência de recursos. Instâncias ECS com uso de memória superior a 85% por mais de 9 horas acumuladas nas últimas 24 horas são classificadas como não conformes. |
Correção rápida não suportada. |
Não |
|
Monitoramento de desempenho |
Instância RDS apresenta risco de alta carga de desempenho (Novidade no Modelo 3.0) |
Uso prolongado e excessivo de CPU, memória ou conexões em uma instância RDS leva a degradação de desempenho, instabilidade e possíveis interrupções. Monitoramento e ação rápida são essenciais. Instâncias RDS são consideradas não conformes se a média de uso de CPU, memória, conexões ou IOPS for igual ou superior a 80% por pelo menos 8 horas nos últimos 7 dias. |
Correção rápida não suportada. |
Não |
|
Monitoramento de desempenho |
Instância Redis apresenta risco de alta carga de desempenho (Novidade no Modelo 3.0) |
Uso contínuo e elevado de CPU ou memória em instâncias Redis pode causar degradação de desempenho, instabilidade e falhas de serviço. Atenção e correção tempestivas são recomendadas. Instâncias Redis com média de uso de CPU ou memória igual ou superior a 80% por mais de 8 horas acumuladas nos últimos 7 dias são consideradas não conformes. |
Correção rápida não suportada. |
Não |
|
Monitoramento de desempenho |
Instância SLB apresenta risco de alta carga de desempenho (Novidade no Modelo 3.0) |
Uso excessivo e prolongado de conexões máximas, novas conexões ou tráfego de saída pela Internet em uma instância SLB resulta em degradação de desempenho, instabilidade e possíveis interrupções. É crucial monitorar e resolver rapidamente. Instâncias SLB com média de uso de conexões máximas, novas conexões ou tráfego de saída igual ou superior a 80% por pelo menos 8 horas nos últimos 7 dias são classificadas como não conformes. |
Correção rápida não suportada. |
Não |
|
Monitoramento de desempenho |
VPN Gateway apresenta risco de alta carga de desempenho (Novidade no Modelo 3.0) |
Largura de banda de entrada ou saída elevada por longos períodos em um VPN Gateway causa degradação de desempenho, instabilidade e possíveis falhas. Recomenda-se monitoramento e ação imediata. Um VPN Gateway é considerado não conforme se o valor máximo de uso de largura de banda de entrada ou saída for igual ou superior a 80% por pelo menos 8 horas nas últimas 24 horas. |
Correção rápida não suportada. |
Não |
|
Utilização de recursos elásticos |
Grupo de dimensionamento ECS corre o risco de não conseguir escalar automaticamente por desempenho |
Recursos principais como ECS podem aumentar ou diminuir automaticamente conforme a carga, garantindo equilíbrio dinâmico durante a operação. |
Correção rápida não suportada. |
Não |
|
Utilização de recursos elásticos |
Auto Scaling não está ativado para RDS (Novidade no Modelo 3.0) |
Sem o recurso de auto scaling ativado, uma instância RDS pode não expandir recursos a tempo durante picos de carga ou não liberar recursos ociosos em períodos de baixa demanda. Isso gera gargalos, latência e até interrupções, além de desperdício de recursos e custos desnecessários. Ativar o auto scaling permite escalonamento elástico e uso eficiente, otimizando custos e garantindo estabilidade e alta disponibilidade do banco de dados. Instâncias RDS sem auto scaling ativado são consideradas não conformes. |
Esta correção ativa a expansão automática de armazenamento para a instância RDS. Após a ativação, o espaço é expandido automaticamente ao atingir o limiar definido. A instância não precisa ser reiniciada durante a expansão, sem impacto nos negócios. |
Não |
|
Design de rede |
Regra de cache não configurada para site ESA |
Este item verifica se o site possui regra de cache configurada para reduzir o tráfego de busca na origem. A ausência dessa configuração indica que as melhores práticas de otimização de rede não estão sendo seguidas. |
Correção rápida não suportada. |
Não |
|
Design de rede |
Smart Routing não está ativado para site ESA em região global |
Este item garante que o Smart Routing esteja ativado para melhorar a aceleração do ESA em regiões globais. A falta dessa ativação significa que as melhores práticas de otimização de rede não foram aplicadas. |
Esta correção ativa o Smart Routing para o site selecionado. O Smart Routing utiliza os nós de borda globais da Alibaba Cloud para detectar condições de rede em tempo real, selecionar rotas otimizadas para transmissão de dados e aplicar otimizações na pilha de protocolos, reduzindo latência e falhas de requisição. O Smart Routing é cobrado por número de requisições (Faturamento). |
Não |
|
Design de rede |
CDN não é usado para acelerar acesso a recursos OSS (Novidade no Modelo 3.0) |
Usar CDN para distribuir recursos estáticos (imagens, vídeos, documentos) armazenados no OSS reduz custos de tráfego e melhora a velocidade de carregamento. O CDN implanta nós de cache em várias regiões globais. Quando um usuário solicita recursos estáticos do OSS, o CDN direciona a requisição ao nó de cache mais próximo, evitando acessos diretos e de longa distância ao OSS. O nó CDN mais próximo entrega o conteúdo em cache sem precisar buscar na origem. Esse processo gera custos de tráfego downstream do CDN, cujo preço unitário é menor que o tráfego de saída do OSS pela Internet. Buckets OSS com tráfego de entrada pela rede pública superior a 100 B em 24 horas, mas sem uso de CDN para otimizar a transferência de dados, são considerados não conformes. |
Correção rápida não suportada. |
Não |
Itens de verificação removidos
Alguns itens de verificação do Modelo 2.0 foram incorporados ao novo Modelo 3.0. Como o Modelo 3.0 já cobre a detecção desses riscos, os seguintes itens foram removidos:
|
Pilar |
Categoria |
Item de verificação |
Descrição do item de verificação |
|
Segurança |
Prevenção de abuso de privilégios |
Muitas identidades RAM receberam permissões de alto risco para OSS e SLS |
Para gerenciar permissões de identidades RAM, recomenda-se seguir o princípio do menor privilégio, concedendo apenas o estritamente necessário. Permissões de alto risco mal gerenciadas podem resultar em perda de dados ou acessos não autorizados. Por exemplo, identidades com permissões como |
|
Segurança |
Prevenção de abuso de privilégios |
Muitas identidades RAM receberam permissões de alto risco para o diretório de recursos |
O diretório de recursos permite gerenciar contas de forma unificada dentro de uma organização, criando novas contas ou removendo existentes. Segundo as melhores práticas, apenas administradores ou líderes de equipes de gestão em nuvem devem ter permissões de escrita no diretório, como ativar/desativar o diretório, criar/convidar/excluir contas e alterar tipos de conta. Normalmente, no máximo 3 pessoas em uma empresa devem ter essa função. Não se recomenda conceder permissões de escrita no diretório a usuários comuns, pois erros operacionais (como exclusão acidental de contas) podem causar danos significativos aos negócios. |
|
Segurança |
Uso de autorização granular |
Existe identidade RAM com escopo convergente de operações de acesso |
Na gestão de permissões de identidades RAM, deve-se aplicar o princípio do menor privilégio. Uma conta é considerada conforme se uma identidade RAM estiver vinculada apenas a algumas permissões operacionais específicas de um serviço de nuvem. |
|
Segurança |
Uso de autorização granular |
Não existe identidade RAM com acesso convergente a OSS e SLS |
Para identidades RAM, recomenda-se conceder apenas as permissões necessárias. Especialmente para produtos de dados como OSS e SLS, a autorização deve ser granular para reduzir riscos de violação por comprometimento de identidade. Se uma identidade RAM tiver permissões relacionadas a produtos de dados, a autorização deve ser detalhada, evitando o uso do caractere curinga * para autorizações em massa. Essa configuração é considerada conforme. |
|
Segurança |
Eficiência e controle de autorização |
Escopo efetivo de política personalizada concedida a identidade RAM não especifica grupo de recursos |
Por padrão, políticas personalizadas concedidas a identidades RAM têm escopo no nível da conta. Se a política não restringir explicitamente recursos ou condições, a identidade terá permissão sobre todos os recursos da conta. Seguindo as melhores práticas, recursos devem ser organizados em grupos, e as autorizações devem ser baseadas nesses grupos. Restringir o escopo efetivo a um grupo de recursos limita melhor as permissões e viabiliza autorização granular. É considerada melhor prática quando o escopo efetivo da política é um grupo de recursos ou quando o grupo é especificado nas condições da política. |
|
Segurança |
Eficiência e controle de autorização |
Nenhuma autorização de identidade RAM com política de sistema no nível de serviço está restrita a um grupo de recursos |
Para identidades RAM, aplique o princípio do menor privilégio. Dividir recursos em grupos por aplicação ou ambiente permite autorizações mais restritivas, reduzindo riscos de permissões excessivas. Uma conta é conforme se uma identidade RAM com política de sistema no nível de serviço (como AliyunECSFullAccess) tiver escopo de autorização limitado a um grupo de recursos. |
|
Segurança |
Eficiência e controle de autorização |
Nenhuma autorização de identidade RAM com permissões Admin está restrita a um grupo de recursos |
Siga o princípio do menor privilégio ao gerenciar identidades RAM. Organizar recursos em grupos por dimensões como aplicação e ambiente permite autorizações mais precisas, minimizando riscos de permissões amplas demais. Contas são consideradas conformes se identidades RAM com permissões AdministratorAccess tiverem escopo de autorização restrito a um grupo de recursos. |
|
Segurança |
Resposta a alertas de não conformidade |
Regras de alerta não definidas para eventos operacionais de risco |
Uma conta é considerada não conforme se nenhuma regra relacionada à segurança da conta ou conformidade operacional do ActionTrail (suportada em alertas de eventos do ActionTrail) estiver ativada. |
|
Segurança |
Habilitar correção automática |
Métodos automatizados não são usados para corrigir problemas de não conformidade |
Contas em que o usuário não ativou a correção automática para nenhuma regra são classificadas como não conformes. |
|
Segurança |
Instâncias de armazenamento de dados devem evitar acesso pela rede pública |
Lista de permissões de IP da instância PolarDB definida como 0.0.0.0/0 |
A lista de permissões de IP define quais endereços podem acessar um cluster PolarDB. Configurações como % ou 0.0.0.0/0 permitem acesso de qualquer IP, reduzindo drasticamente a segurança do banco de dados. Use apenas se estritamente necessário. As melhores práticas recomendam aplicar o princípio do menor privilégio e configurar listas de permissões adequadas para proteger o cluster PolarDB. Configurar a lista como 0.0.0.0/0 ou % não é considerado boa prática. |
|
Segurança |
Instâncias de armazenamento de dados devem evitar acesso pela rede pública |
Lista de permissões de IP da instância RDS definida como 0.0.0.0/0 |
A lista de permissões de IP controla o acesso a instâncias RDS. Definir como 0.0.0.0/0 permite acesso irrestrito, comprometendo a segurança do banco de dados. Evite essa configuração salvo necessidade extrema. Siga o princípio do menor privilégio e configure listas apropriadas para proteger a instância. Configuração 0.0.0.0/0 não atende às melhores práticas. |
|
Segurança |
Instâncias de armazenamento de dados devem evitar acesso pela rede pública |
Lista de permissões de IP da instância Redis definida como 0.0.0.0/0 |
Listas de permissões de IP determinam quem pode acessar uma instância Redis. Valores como 0.0.0.0/0 abrem acesso total, reduzindo significativamente a segurança. Use apenas quando indispensável. Recomenda-se aplicar o princípio do menor privilégio e definir listas restritivas para proteger a instância. Configurar como 0.0.0.0/0 viola as melhores práticas. |
|
Segurança |
Instâncias de armazenamento de dados devem evitar acesso pela rede pública |
Lista de permissões de IP da instância MongoDB definida como 0.0.0.0/0 |
A lista de permissões de IP regula o acesso a instâncias MongoDB. Configurar como 0.0.0.0/0 permite acesso universal, enfraquecendo a segurança do banco. Evite exceto se absolutamente necessário. Adote o princípio do menor privilégio e configure listas adequadas para proteção. Valor 0.0.0.0/0 não segue as melhores práticas. |
|
Segurança |
Instâncias de armazenamento de dados devem evitar acesso pela rede pública |
Lista de permissões de IP da instância Elasticsearch definida como 0.0.0.0/0 |
Listas de permissões de IP controlam o acesso a instâncias Elasticsearch. Configurações como 0.0.0.0/0 ou ::/0 permitem acesso irrestrito, comprometendo a segurança. Use apenas em casos excepcionais. Siga o princípio do menor privilégio e defina listas restritivas para proteger a instância. Valores 0.0.0.0/0 ou ::/0 não atendem às melhores práticas. |
|
Estabilidade |
Proteção contra exclusão |
Proteção contra liberação não ativada para recurso Redis |
Instâncias Redis sem proteção contra liberação ativada são consideradas não conformes. |
|
Estabilidade |
Proteção contra exclusão |
Proteção contra liberação não ativada para recurso ECS |
Instâncias ECS sem proteção contra liberação ativada são classificadas como não conformes. |
|
Estabilidade |
Gestão de mudanças |
Janela de manutenção inadequada para recurso Redis |
Instâncias Redis com período de backup automático fora dos intervalos 04:00-05:00, 05:00-06:00 ou 12:00-13:00 são consideradas não conformes. |
|
Estabilidade |
Gestão de mudanças |
Janela de manutenção inadequada para recurso PolarDB |
Clusters PolarDB com janela de manutenção fora dos intervalos 02:00-04:00 ou 06:00-10:00 são classificados como não conformes. |
|
Estabilidade |
Gestão de mudanças |
Janela de manutenção inadequada para recurso ADB |
Clusters ADB com janela de manutenção fora dos intervalos 02:00-04:00, 06:00-08:00 ou 12:00-13:00 são considerados não conformes. |
|
Estabilidade |
Gestão de mudanças |
Janela de manutenção inadequada para recurso RDS |
Instâncias RDS com janela de manutenção fora dos intervalos 02:00-06:00 ou 06:00-10:00 são classificadas como não conformes. |
|
Estabilidade |
Gestão de mudanças |
Janela de manutenção inadequada para recurso ECS |
Criar snapshots de instâncias ECS reduz temporariamente o desempenho de E/S do armazenamento em bloco. Políticas de snapshot automático com horários de criação fora dos valores 1 ou 2 são consideradas não conformes. |
|
Custo |
Otimização de custos de recursos |
Pacote de conformidade "Melhores Práticas para Detecção de Recursos Ociosos" não ativado |
Contas sem o pacote de conformidade de detecção de recursos ociosos ativado no Cloud Config são consideradas não conformes. |
|
Eficiência |
Agrupamento e isolamento de recursos |
Múltiplas contas não são usadas para gerenciar recursos na mesma organização |
Uma conta Alibaba Cloud tem múltiplos significados. Cada conta é um tenant completamente isolado, com acesso a recursos, implantação de rede e permissões de identidade independentes por padrão. Como cada conta está associada a uma fatura, diferentes serviços podem ser implantados em contas distintas para contabilidade e faturamento separados. A gestão multiconta traz benefícios em isolamento de ambientes, conformidade de segurança e inovação nos negócios. A condição é atendida se houver duas ou mais contas Alibaba Cloud sob a mesma entidade. |
|
Eficiência |
Qualidade da automação |
Cota ECS em risco de saturação |
Criação, alteração ou uso de recursos/features de produtos pode encontrar exceções. Um produto é considerado em risco se tiver algum item de cota de recurso com nível elevado nos últimos 7 dias e tiver encontrado erro quota_exceed. |
|
Eficiência |
Qualidade da automação |
Cota VPC em risco de saturação |
Operações de criação, modificação ou uso de funcionalidades de produtos podem falhar. Produtos com itens de cota de recurso em nível alto nos últimos 7 dias e erros quota_exceed são considerados em risco. |
|
Eficiência |
Qualidade da automação |
Cota SLB em risco de saturação |
Exceções podem ocorrer durante criação, alteração ou uso de recursos de produtos. Se um produto apresentou item de cota com nível elevado nos últimos 7 dias e erro quota_exceed, ele está em risco. |
|
Eficiência |
Qualidade da automação |
Cota CEN em risco de saturação |
Falhas podem surgir em operações de provisionamento, mudança ou uso de features. Produtos com cotas em nível alto nos últimos 7 dias e erros quota_exceed são classificados como em risco. |
|
Eficiência |
Qualidade da automação |
Cota ACK em risco de saturação |
Criação, modificação ou uso de recursos pode gerar exceções. Produtos com itens de cota elevados nos últimos 7 dias e erros quota_exceed são considerados em risco. |
|
Eficiência |
Qualidade da automação |
Cota CDN em risco de saturação |
Operações de recursos ou funcionalidades podem apresentar falhas. Se um produto teve cota em nível alto nos últimos 7 dias e encontrou erro quota_exceed, ele está em situação de risco. |