Empresas e organizações que utilizam sistemas computadorizados na indústria farmacêutica devem cumprir as diretrizes para sistemas computadorizados do padrão Boas Práticas de Fabricação (GMP) para Medicamentos ao adotar serviços em nuvem. O modelo de pacote de conformidade CNGMPComplianceCheck mapeia os requisitos do padrão para as configurações dos produtos Alibaba Cloud. A tabela a seguir descreve as regras padrão neste modelo de pacote de conformidade.
|
A avaliação é considerada compatível se existir uma trilha ativa no ActionTrail com rastreamento de todos os tipos de eventos gerados em todas as regiões. Caso o administrador de um diretório de recursos tenha criado uma trilha aplicável a todos os membros, o resultado também será considerado compatível. |
|
O gerenciamento de riscos deve abranger todo o ciclo de vida de um sistema computadorizado, considerando a segurança do paciente, a integridade dos dados e a qualidade do produto. Como parte do gerenciamento de riscos de qualidade, aplique esse gerenciamento para confirmar o escopo de validação e o nível de controle de integridade dos dados exigidos, com base nos resultados da sua avaliação de riscos documentada. O sistema computadorizado deve registrar a identidade de cada operador que insere ou verifica dados essenciais. Apenas operadores autorizados podem modificar dados inseridos. Sempre que um operador alterar um dado essencial existente, a operação deve ser aprovada e o motivo da alteração registrado. A empresa pode implementar um sistema de rastreamento para auditar dados no sistema computadorizado conforme o resultado da avaliação de riscos, permitindo o registro de inserções e modificações de dados. Elabore um guia operacional sobre como lidar com falhas ou danos no sistema. Verifique o conteúdo desse guia quando necessário. Todos os incidentes, incluindo falhas de sistema e erros de dados, devem ser registrados e avaliados. Investigue incidentes graves, identifique suas causas raízes e adote as medidas corretivas e preventivas necessárias. |
|
|
O uso do Security Center Enterprise Edition ou de uma edição superior resulta em uma avaliação compatível. |
|
O gerenciamento de riscos deve cobrir todo o ciclo de vida do sistema computadorizado, levando em conta a segurança do paciente, a integridade dos dados e a qualidade do produto. No contexto da gestão de riscos de qualidade, aplique o gerenciamento de riscos para definir o escopo de validação e o nível de controle de integridade dos dados necessários, fundamentado na sua avaliação de riscos escrita. Desenvolva um guia operacional para tratar falhas ou danos no sistema e valide seu conteúdo se for preciso. Registre e avalie todos os incidentes, como falhas de sistema e defeitos em dados. Para incidentes críticos, realize investigações para encontrar as causas raízes e implemente as ações corretivas e preventivas adequadas. |
|
|
Garantir que a proteção do Security Center esteja ativada para instâncias ECS em execução |
A conformidade é atingida quando um agente do Security Center está instalado em cada instância do Elastic Compute Service (ECS). Esta regra aplica-se apenas a instâncias ECS em execução. |
4.7 |
Mantenha um inventário atualizado com os detalhes de todos os sistemas computadorizados, especificando as funcionalidades relacionadas à gestão da qualidade na fabricação de medicamentos. Atualize esse inventário assim que possível. |
|
Instâncias ECS em execução livres de vulnerabilidades não corrigidas |
Se o Security Center não detectar vulnerabilidades não corrigidas de um tipo ou nível específico em uma instância ECS, a avaliação é considerada compatível. A regra vigora somente para instâncias ECS ativas. |
4.7 |
Crie um inventário detalhado de todos os sistemas computadorizados, destacando os recursos ligados à gestão de qualidade na produção farmacêutica. Atualize imediatamente esse inventário quando houver mudanças. |
|
Nenhuma instância ECS no estado Stopped resulta em uma avaliação compatível. |
4.7 |
Construa um inventário que liste todos os sistemas computadorizados e especifique as funcionalidades associadas à gestão da qualidade na manufatura de fármacos. Garanta que o inventário seja atualizado na primeira oportunidade. |
|
|
A conformidade é verificada quando cada endereço IP elástico (EIP) está associado a uma instância ECS ou a um gateway NAT. |
4.7 |
Elabore um inventário contendo informações sobre todos os sistemas computadorizados, detalhando os recursos pertinentes à gestão de qualidade farmacêutica. Mantenha o inventário sempre atualizado. |
|
|
O resultado da avaliação é Compatível se cada grupo de segurança possuir pelo menos uma instância ECS adicionada. |
4.7 |
Mantenha um inventário completo dos sistemas computadorizados, indicando claramente as características voltadas para a gestão da qualidade na fabricação de medicamentos. Atualize-o prontamente. |
|
|
A ativação do recurso de backup de log em cada instância do ApsaraDB RDS torna a avaliação compatível. |
|
Ao converter formatos ou migrar dados, garanta que seus valores e definições permaneçam inalterados. Quando um operador inserir dados críticos, como peso e ID de lote de materiais durante a pesagem, ele deve revisar os registros para assegurar a precisão. Essa revisão pode ser feita por outro operador ou por uma aplicação validada. Configure o recurso de revisão no sistema se necessário, garantindo a exatidão dos dados inseridos e seu processamento correto. Se a maior parte dos dados da empresa for digital, cumpra os seguintes requisitos: 2. Assegure a segurança dos dados por meios físicos ou eletrônicos, evitando danos intencionais ou acidentais. Caso ocorram alterações no sistema durante operações diárias e manutenção (como em computadores ou aplicações), verifique a acessibilidade e a integridade dos dados armazenados. 3. Crie um guia operacional para backup e restauração de dados, realizando backups regulares para preservar as informações para uso futuro. Armazene os backups em local separado e seguro, respeitando o período de retenção exigido pelo padrão para arquivos e registros. Desenvolva um plano de resposta a emergências e acione-o em caso de danos ao sistema. A rapidez do acionamento depende da urgência do problema; por exemplo, informações que impactem o recall de produtos devem ser obtidas o mais rápido possível. |
|
|
Retenção de backup de log para clusters PolarDB atende aos requisitos especificados |
A avaliação é considerada compatível se o período de retenção dos backups de log de cada cluster PolarDB for igual ou superior ao número de dias especificado. Valor padrão: 30. Unidade: dias. Se o backup de log estiver desativado ou se a retenção for inferior ao período definido, o resultado será não compatível. |
|
Durante a conversão de formatos ou migração de dados, assegure que o valor e a definição dos dados não sofram alterações. Ao inserir dados fundamentais, como o peso e o ID de lote de materiais na pesagem, o operador precisa revisar os registros para garantir a correção. A revisão pode ser executada por outro operador ou por uma aplicação validada. Se necessário, configure a funcionalidade de revisão no sistema para garantir a precisão das entradas e o processamento adequado dos dados. Para empresas com predominância de dados digitais, atenda aos seguintes requisitos: 2. Proteja os dados usando métodos físicos ou eletrônicos contra danos intencionais e não intencionais. Se houver mudanças no sistema durante a operação e manutenção diária (computadores ou aplicativos), verifique a acessibilidade e integridade dos dados armazenados. 3. Estabeleça um guia de procedimentos para backup e restauração, fazendo backups periódicos para proteger os dados armazenados. Os backups devem ficar em um local seguro e distinto, com período de retenção alinhado às normas para arquivos e registros. Tenha um plano de emergência pronto para ser ativado caso o sistema sofra danos, sendo a velocidade de ativação proporcional à gravidade do incidente. Informações críticas, como as que afetam recalls, devem ser recuperadas imediatamente. |
|
A conformidade é alcançada quando o backup incremental está habilitado em cada instância do ApsaraDB for Redis. Esta regra aplica-se exclusivamente a instâncias Tair. |
|
Na conversão ou migração de dados, preserve integralmente seus valores e definições. Operadores que inserem dados chave (ex.: peso e ID de lote na pesagem) devem revisar os registros para validar a exatidão. Outra pessoa ou uma aplicação validada pode fazer essa revisão. Configure o sistema para suportar essa revisão, assegurando dados precisos e processamento esperado. Se os dados da empresa forem majoritariamente digitais, siga estas regras: 2. Garanta a segurança dos dados via métodos físicos ou eletrônicos, prevenindo danos acidentais ou propositais. Mudanças no sistema durante rotinas de operação e manutenção exigem verificação da integridade e acesso aos dados armazenados. 3. Documente os procedimentos de backup e restauração e execute backups frequentes para salvaguardar os dados. Guarde os backups em local seguro e segregado, obedecendo aos prazos de retenção normativos. Prepare um plano de contingência para danos no sistema, ativando-o conforme a urgência da situação. Dados que influenciam recalls de produtos requerem obtenção imediata. |
|
|
Habilitar o backup automático em cada cluster Elasticsearch resulta em conformidade na avaliação. |
|
Certifique-se de que a conversão ou migração de dados não altere seus valores e definições. A revisão dos registros por um operador (ou aplicação validada) é obrigatória após a entrada de dados críticos, como peso e lote de materiais. Habilite a função de revisão no sistema para garantir a precisão e o processamento correto. Para ambientes com muitos dados digitais, é necessário: 2. Proteger os dados contra danos (intencionais ou não) usando barreiras físicas ou eletrônicas. Verifique a integridade e acessibilidade dos dados sempre que houver manutenção ou mudanças operacionais no sistema. 3. Ter um guia de backup e restauração, realizando cópias regulares em local seguro e separado. O tempo de retenção deve seguir o padrão. Um plano de emergência deve existir para casos de dano ao sistema, com tempo de resposta ajustado à criticidade (ex.: dados de recall prioritários). |
|
|
A avaliação considera compatível quando o backup de log está ativo em cada cluster AnalyticDB. |
|
Ao migrar ou converter formatos de dados, mantenha inalterados seus valores e definições. Dados essenciais (como peso e ID de lote) exigem revisão pós-inserção pelo operador ou por software validado para garantir exatidão. Configure o sistema para permitir essa revisão. Se a empresa opera principalmente com dados digitais, cumpra: 2. Segurança de dados via meios físicos/eletrônicos contra danos. Verificação de integridade/acesso após mudanças operacionais ou de manutenção. 3. Guia operacional de backup/restauração com execuções regulares em local seguro e isolado, respeitando a retenção normativa. Plano de emergência para danos no sistema, com ativação rápida conforme a gravidade (priorizando informações de recall). |
|
|
Cada instância do ApsaraDB for MongoDB com backup de log ativado resulta em avaliação compatível. |
|
Garanta que valores e definições dos dados não mudem durante conversões ou migrações. Revise os registros de dados críticos (peso, lote) após a inserção, seja manualmente ou via aplicação validada. A configuração do recurso de revisão no sistema é recomendada para assegurar precisão. Requisitos para dados majoritariamente digitais: 2. Proteção física/eletrônica contra danos aos dados. Verificação de integridade após manutenções ou alterações. 3. Procedimentos documentados de backup e restauração, com cópias frequentes em local seguro. Retenção conforme norma. Plano de contingência para falhas sistêmicas, com resposta ágil para dados críticos (recall). |
|
|
A existência de um plano de backup para cada sistema de arquivos File Storage NAS torna a avaliação compatível. |
|
Preserve valores e definições originais ao converter ou migrar dados. A revisão de entradas de dados essenciais (ex.: pesagem de materiais) é obrigatória para garantir correção, podendo ser feita por humano ou sistema validado. Configure o sistema para tal fim. Para dados digitais, exige-se: 2. Segurança contra danos (física/eletrônica). Validação de integridade pós-manutenção. 3. Rotina de backup e restauração documentada e executada regularmente em local seguro. Respeito aos prazos de retenção. Plano de emergência com ativação escalonada conforme a gravidade (prioridade para recalls). |
|
|
Definir uma política de snapshot automático para cada disco ECS resulta em conformidade. |
|
Não altere valores ou definições de dados durante migrações ou conversões. Valide a exatidão de dados críticos inseridos através de revisão humana ou automatizada. Configure o sistema para suportar essa validação. Requisitos para predominância de dados digitais: 2. Proteção de dados contra danos intencionais/acidentais. Verificação de integridade após intervenções no sistema. 3. Backup regular em local seguro e isolado, seguindo normas de retenção. Plano de resposta a incidentes com tempo de ativação baseado na criticidade (dados de recall são prioritários). |
|
|
A avaliação é compatível se o backup de banco de dados estiver habilitado em cada cluster do ApsaraDB for OceanBase. |
|
Mantenha a integridade (valor e definição) dos dados em processos de conversão ou migração. Assegure a correção de dados essenciais mediante revisão pós-inserção (manual ou via aplicação validada). Configure o sistema para permitir tais revisões. Para dados digitais, observe: 2. Segurança física/eletrônica contra danos. Auditoria de integridade após manutenções. 3. Rotinas de backup e restauração documentadas e frequentes, com armazenamento seguro. Cumprimento dos prazos de retenção. Plano de emergência com ativação proporcional à urgência (foco em recalls). |
|
|
Sem o versionamento, a restauração de dados sobrescritos ou excluídos pode falhar. Com o versionamento ativado, a avaliação é considerada compatível. |
|
Assegure que conversões e migrações preservem valores e definições dos dados. Revise dados críticos inseridos para garantir exatidão (via operador ou sistema validado). Configure o recurso de revisão no sistema. Requisitos para dados digitais: 2. Proteção contra danos (física/eletrônica). Verificação de integridade pós-alteração/manutenção. 3. Backup periódico em local seguro/separado, respeitando retenção normativa. Plano de contingência com resposta escalonada (prioridade para recalls). |
|
|
A conformidade é atingida quando o armazenamento redundante de zona (ZRS) está habilitado em cada bucket do Object Storage Service (OSS). Sem ZRS, o OSS não garante serviços consistentes nem recuperação de dados se um data center ficar indisponível. |
|
Valores e definições de dados devem permanecer intactos durante conversões ou migrações. A revisão de dados essenciais (ex.: pesagem) é obrigatória para validar a entrada. Configure o sistema para essa finalidade. Para dados digitais: 2. Segurança contra danos intencionais/acidentais. Verifique a integridade após manutenções. 3. Backups regulares em local seguro, seguindo normas de retenção. Plano de emergência com ativação baseada na criticidade (recalls prioritários). |
|
|
O uso de conexões seguras SSL nos bancos de source e destino de cada tarefa de sincronização em uma instância do Data Transmission Service (DTS) torna a avaliação compatível. Aplica-se apenas a tarefas de sincronização. |
|
Garanta a preservação de valores e definições ao converter ou migrar dados. Revise dados críticos inseridos para assegurar precisão (humano ou sistema validado). Configure o sistema para permitir revisão. Isso garante a exatidão dos dados e seu processamento correto. |
|
|
Trabalhos de migração DTS conectam-se a bancos de source e destino usando SSL |
A conformidade é verificada quando conexões SSL seguras são usadas nos bancos de source e destino de cada tarefa de migração em uma instância DTS. Vigora apenas para tarefas de migração. |
|
Mantenha valores e definições inalterados em conversões/migrações. A revisão de dados essenciais pós-inserção é necessária para garantir correção. Configure o sistema para suportar essa revisão, assegurando precisão e processamento adequado. |
|
Verifique se TLS 1.3 está ativado para nome de domínio acelerado |
A ativação do protocolo Transport Layer Security (TLS) 1.3 em cada nome de domínio CDN resulta em avaliação compatível. |
|
Ao converter ou migrar dados, preserve seus valores e definições. Revise entradas de dados críticos para garantir exatidão. Configure o sistema para permitir revisões, assegurando precisão e processamento esperado. |
|
Habilitar HTTPS em cada instância Elasticsearch torna a avaliação compatível. |
|
Garanta que valores e definições não mudem em conversões ou migrações. Revise dados essenciais inseridos para validar a correção. Configure o sistema para revisões, garantindo precisão e processamento correto. |
|
|
A avaliação é compatível se cada função no Function Compute estiver vinculada a um nome de domínio personalizado com uma versão específica de TLS habilitada. |
|
Preserve valores e definições ao converter/migrar dados. Revise dados críticos inseridos para assegurar exatidão. Configure o sistema para revisões, garantindo precisão e processamento adequado. |
|
|
A ativação da criptografia SSL em cada cluster PolarDB resulta em conformidade. |
|
Mantenha a integridade (valor/definição) dos dados em conversões/migrações. Revise entradas de dados essenciais para garantir correção. Configure o sistema para revisões, assegurando precisão e processamento esperado. |
|
|
A avaliação é considerada compatível quando a criptografia SSL está habilitada em cada instância do ApsaraDB for Redis. |
|
Ao converter ou migrar dados, garanta que valores e definições não sejam alterados. Revise dados críticos inseridos para validar a exatidão. Configure o sistema para permitir revisões, garantindo precisão e processamento correto. |
|
|
APIs do API Gateway com acesso à rede pública devem usar HTTPS |
A conformidade é atingida se o método de solicitação de cada API com acesso à Internet no API Gateway estiver definido como HTTPS. A regra não se aplica a APIs de acesso apenas interno. |
|
Garanta a preservação de valores e definições em conversões/migrações de dados. Revise dados essenciais inseridos para assegurar correção. Configure o sistema para revisões, garantindo precisão e processamento adequado. |
|
A ativação do recurso de certificado SSL nas configurações de segurança de dados de cada instância do ApsaraDB RDS torna a avaliação compatível. |
|
Valores e definições de dados devem permanecer inalterados durante conversões ou migrações. Revise dados críticos inseridos para garantir exatidão. Configure o sistema para revisões, assegurando precisão e processamento esperado. |
|
|
A avaliação é compatível se a criptografia estiver ativada em cada disco de dados ECS em uso. |
5.19 |
Para empresas com maioria de dados digitais, cumpra: 2. Segurança de dados (física/eletrônica) contra danos intencionais/acidentais. Verifique integridade e acesso após manutenções ou alterações. 3. Guia de backup/restauração com execuções regulares em local seguro. Retenção conforme norma. |
|
|
A conformidade é verificada quando a Criptografia Transparente de Dados (TDE) está habilitada nas configurações de segurança de cada instância do ApsaraDB RDS. |
5.19 |
Se os dados forem predominantemente digitais: 2. Proteja-os contra danos (física/eletronicamente). Valide integridade após mudanças operacionais. 3. Realize backups regulares em local seguro, seguindo prazos de retenção normativos. |
|
|
Habilitar um algoritmo de criptografia em cada conexão VPN resulta em avaliação compatível. |
5.19 |
Para dados majoritariamente digitais: 2. Segurança contra danos (física/eletrônica). Verificação de integridade pós-manutenção. 3. Backups periódicos em local seguro e isolado, respeitando a retenção exigida. |
|
|
Criptografia de disco ativada em nós de dados de instância Elasticsearch |
A ativação da criptografia de disco nos nós de dados de cada cluster Elasticsearch torna a avaliação compatível. |
5.19 |
Requisitos para dados digitais: 2. Proteção contra danos intencionais/acidentais. Auditoria de integridade após alterações. 3. Rotina de backup em local seguro, cumprindo prazos de retenção. |
|
A avaliação é compatível se o recurso TDE estiver habilitado nas configurações de segurança de dados de cada cluster PolarDB. |
5.19 |
Para predominância de dados digitais: 2. Segurança física/eletrônica contra danos. Verificação de integridade pós-manutenção. 3. Backups regulares em local seguro, seguindo normas de retenção. |
|
|
O uso de chave personalizada para ativar TDE em cada instância do ApsaraDB for Redis resulta em conformidade. |
5.19 |
Dados digitais exigem: 2. Proteção contra danos (física/eletrônica). Validação de integridade após mudanças. 3. Backup periódico em local seguro, respeitando retenção normativa. |
|
|
Ative criptografia de dados em Logstores do Simple Log Service |
A conformidade é atingida quando a criptografia de dados está habilitada em cada Logstore do Simple Log Service. |
5.19 |
Para dados majoritariamente digitais: 2. Segurança contra danos intencionais/acidentais. Verifique integridade após manutenções. 3. Backups em local seguro e separado, cumprindo prazos de retenção. |
|
Snapshots automáticos do ECS retidos pelo número de dias exigido |
A avaliação é compatível se os snapshots automáticos das instâncias ECS forem retidos por um período igual ou superior ao número de dias especificado. Valor padrão: 7. Unidade: dias. |
5.19 |
Requisitos para dados digitais: 2. Proteção física/eletrônica contra danos. Verificação de integridade pós-alteração. 3. Rotina de backup em local seguro, seguindo normas de retenção. |
|
A ativação da proteção contra exclusão em cada instância RDS torna a avaliação compatível. A regra não se aplica a instâncias do ApsaraDB RDS por assinatura. |
|
Alterações em sistemas computadorizados devem seguir um guia operacional predefinido, incluindo avaliação, validação, revisão, aprovação e execução. Proprietários do sistema devem aprovar mudanças, que devem ser registradas. Valide alterações significativas. Tenha um plano de emergência para danos no sistema, com ativação baseada na urgência (ex.: recalls prioritários). |
|
|
A conformidade é verificada quando a proteção contra exclusão está habilitada em cada cluster PolarDB. Não se aplica a clusters por assinatura. |
|
Mudanças no sistema computadorizado exigem guia operacional (avaliação, validação, aprovação, execução). Aprovação pelos proprietários e registro detalhado são obrigatórios. Valide grandes mudanças. Plano de emergência para danos, com resposta proporcional à gravidade (foco em recalls). |
|
|
Habilitar a proteção contra liberação em cada instância ECS resulta em avaliação compatível. |
|
Siga um guia operacional para alterações no sistema (avaliar, validar, aprovar, executar). Registre detalhes e obtenha aprovação dos proprietários. Valide mudanças críticas. Acione o plano de emergência em caso de danos, priorizando informações de recall. |
|
|
A avaliação é compatível se a proteção contra exclusão estiver ativa em cada cluster do ApsaraDB for HBase. Não se aplica a clusters por assinatura. |
|
Alterações sistêmicas requerem guia operacional (avaliação, validação, aprovação). Registre tudo e valide mudanças maiores. Plano de emergência para danos, com ativação urgente para dados de recall. |
|
|
A conformidade é atingida com a proteção contra liberação habilitada em cada instância do ApsaraDB for MongoDB. Exceto para instâncias por assinatura. |
|
Execute mudanças conforme guia operacional (avaliar, validar, aprovar, registrar). Valide alterações significativas. Plano de contingência para danos, com resposta rápida para recalls. |
|
|
A avaliação é compatível quando a proteção contra liberação está ativa em cada instância do ApsaraDB for Redis. Não se aplica a instâncias por assinatura. |
|
Mudanças exigem guia operacional (avaliação, validação, aprovação, registro). Valide alterações críticas. Plano de emergência para danos, priorizando recalls. |
|
|
Habilitar a proteção contra liberação em cada instância do Server Load Balancer (SLB) resulta em conformidade. |
|
Siga procedimentos operacionais para alterações (avaliar, validar, aprovar, registrar). Valide mudanças maiores. Plano de emergência com ativação baseada na criticidade (recalls prioritários). |
|
|
Agente do CloudMonitor instalado em instâncias ECS em execução |
A conformidade é verificada se o agente do CloudMonitor estiver instalado e funcionando corretamente em cada instância ECS em execução. Aplica-se apenas a instâncias ativas. |
5.21 |
Elabore um guia para falhas ou danos no sistema e valide-o se necessário. Registre e avalie todos os incidentes. Investigue causas raízes de incidentes graves e adote medidas corretivas/preventivas. |
|
A ativação do histórico de eventos em cada instância do ApsaraDB RDS torna a avaliação compatível. |
5.16 |
O sistema deve registrar a identidade de quem insere ou verifica dados essenciais. Apenas autorizados podem modificar dados, com aprovação e registro do motivo. Implemente rastreamento para auditoria conforme avaliação de riscos. |
|
|
A avaliação é compatível se a autenticação multifator (MFA) estiver habilitada em cada conta Alibaba Cloud. |
5.14 |
Restrinja a entrada/modificação de dados a operadores autorizados (senhas, cartões, chaves). Documente procedimentos de autorização e troca de senhas. Configure o sistema para registrar tentativas de acesso não autorizado. Se o controle manual falhar, documente logs operacionais e isolamento físico para garantir que apenas autorizados operem. |
|
|
A conformidade é atingida quando o MFA está ativado nas configurações de login de cada usuário do Resource Access Management (RAM) com acesso ao console. |
5.14 |
Limite a manipulação de dados a pessoal autorizado. Use senhas individuais, chaves e controle de acesso. Documente gestão de autorizações e senhas. Registre tentativas de acesso indevido. Se necessário, documente logs e isolamento físico para garantir operações apenas por autorizados. |
|
|
ACLs de bucket OSS não podem ser definidas como leitura-gravação pública |
A avaliação é compatível se a política de lista de controle de acesso (ACL) de cada bucket OSS negar leitura e gravação pela Internet. |
5.14 |
Apenas autorizados podem manipular dados. Implemente controles de acesso (senhas, chaves). Documente procedimentos de autorização. Registre acessos não autorizados. Garanta operações restritas via logs e isolamento físico se o controle manual for insuficiente. |
|
A conformidade é verificada se nenhuma política de autorização de bucket OSS conceder permissões de leitura/gravação a anônimos. A ausência de políticas também é compatível. |
5.14 |
Restrinja operações a autorizados. Use autenticação forte e controle de acesso. Documente gestão de permissões. Monitore acessos indevidos. Assegure operações válidas via logs e isolamento físico quando necessário. |
|
|
Atribuir uma função RAM a cada instância ECS resulta em avaliação compatível. |
5.14 |
Controle rigoroso de acesso a dados (apenas autorizados). Use senhas, chaves e restrições de acesso. Documente autorizações. Registre tentativas de acesso inválido. Garanta operações seguras via logs e isolamento físico se necessário. |
|
|
A configuração de uma função vinculada ao serviço para o Function Compute torna a avaliação compatível. Isso evita a exposição de pares AccessKey da conta Alibaba Cloud. |
5.14 |
Permita manipulação de dados apenas a autorizados. Implemente autenticação e controle de acesso. Documente gestão de permissões. Monitore acessos não autorizados. Assegure operações válidas via logs e isolamento físico. |
|
|
A avaliação é compatível se o recurso RAM Roles for Service Accounts (RRSA) estiver habilitado em cada cluster do Container Service for Kubernetes (ACK). O RRSA isola o acesso à API por pod, permitindo isolamento granular de permissões e reduzindo riscos. |
5.14 |
Restrinja operações a pessoal autorizado. Use autenticação forte. Documente autorizações e trocas de senha. Registre acessos indevidos. Garanta segurança via logs e isolamento físico se o controle manual falhar. |
|
|
A conformidade é atingida quando apenas um dos recursos (acesso ao console ou acesso à API) está habilitado para cada usuário RAM. |
5.14 |
Apenas autorizados podem manipular dados. Implemente controles de acesso e autenticação. Documente procedimentos de autorização. Monitore acessos inválidos. Assegure operações seguras via logs e isolamento físico. |
|
|
Autenticação obrigatória para clusters MSE com acesso à rede pública |
A avaliação é compatível se a autenticação estiver habilitada em cada cluster do Microservices Engine (MSE) com acesso público, ou se o acesso público for negado. |
5.14 |
Controle estrito de acesso a dados (apenas autorizados). Use senhas e restrições. Documente autorizações. Registre tentativas de acesso não autorizado. Garanta operações válidas via logs e isolamento físico. |
|
A conformidade é verificada se o tempo desde o último uso do par AccessKey de cada usuário RAM for menor que o número de dias especificado. Valor padrão: 90. Unidade: dias. |
5.14 |
Restrinja manipulação de dados a autorizados. Implemente autenticação e controle de acesso. Documente gestão de permissões. Monitore acessos indevidos. Assegure operações seguras via logs e isolamento físico. |
|
|
A avaliação é compatível se as políticas de senha de cada usuário RAM atenderem aos valores especificados. |
5.14 |
Apenas autorizados podem operar dados. Use autenticação forte e controle de acesso. Documente autorizações. Registre acessos não autorizados. Garanta operações válidas via logs e isolamento físico. |
|
|
Verifica se usuário RAM fez login dentro de um período especificado |
A conformidade é atingida se cada usuário RAM tiver feito login pelo menos uma vez nos últimos 90 dias. Usuários atualizados nesse período também são compatíveis, independente do login. Aplica-se apenas a usuários com acesso ao console habilitado. |
5.14 |
Controle rigoroso de acesso a dados. Implemente autenticação e restrições. Documente autorizações. Monitore acessos indevidos. Assegure operações seguras via logs e isolamento físico. |
|
Rotacionar AccessKeys de usuário RAM após período especificado |
A avaliação é compatível se o tempo desde a criação do par AccessKey de cada usuário RAM for menor ou igual ao número de dias especificado. Valor padrão: 90. Unidade: dias. |
5.14 |
Restrinja operações a autorizados. Use autenticação forte. Documente gestão de permissões. Registre tentativas de acesso não autorizado. Garanta operações válidas via logs e isolamento físico. |
|
Instâncias Redis com logs de auditoria habilitados são compatíveis. Versões sem suporte a logs de auditoria são consideradas não aplicáveis. |
5.16 |
Registre a identidade de quem insere/verifica dados essenciais. Modificações exigem aprovação e registro do motivo. Implemente rastreamento para auditoria conforme avaliação de riscos. |
|
|
A ativação do log de auditoria em cada instância MongoDB torna a avaliação compatível. |
5.16 |
O sistema deve registrar identidade de operadores de dados essenciais. Modificações requerem aprovação e justificativa registrada. Use rastreamento para auditoria baseada em riscos. |
|
|
A conformidade é verificada quando o recurso de logging está habilitado para cada bucket OSS na página Logs. |
5.16 |
Registre identidade de quem manipula dados essenciais. Aprovação e registro de motivo são obrigatórios para modificações. Implemente auditoria via rastreamento conforme riscos. |
|
|
A avaliação é compatível se a coleta de logs estiver habilitada para cada nome de domínio protegido pelo Web Application Firewall (WAF) V2.0. |
5.16 |
Identidade de operadores de dados essenciais deve ser registrada. Modificações exigem aprovação e justificativa. Use rastreamento para auditoria baseada em avaliação de riscos. |
|
|
Período de retenção de log de auditoria SQL para instância RDS atende ao requisito especificado |
A conformidade é atingida quando o explorador e auditoria SQL estão habilitados em cada instância do ApsaraDB RDS for MySQL, com retenção de logs igual ou superior aos dias especificados. Valor padrão: 180. Unidade: dias. |
5.16 |
Registre identidade de operadores de dados críticos. Modificações requerem aprovação e registro. Implemente auditoria via rastreamento conforme riscos. |
|
A avaliação é compatível se o explorador e auditoria SQL estiverem habilitados em cada cluster do AnalyticDB for MySQL. |
5.16 |
Identidade de operadores de dados essenciais deve ser registrada. Aprovação e justificativa são obrigatórias para modificações. Use rastreamento para auditoria. |
|
|
A conformidade é verificada quando o log de acesso está habilitado em cada instância SLB. Aplica-se apenas a instâncias com monitoramento de Camada 7 ativo. |
5.16 |
Registre identidade de quem manipula dados críticos. Modificações exigem aprovação e registro. Implemente auditoria via rastreamento conforme riscos. |
|
|
A avaliação é compatível se cada instância do ApsaraDB RDS usar arquitetura multizona. |
5.20 |
Tenha um plano de emergência para danos no sistema, com ativação baseada na urgência. Informações de recall devem ser obtidas imediatamente. |
|
|
A conformidade é atingida quando cada instância do ApsaraDB for Redis usa arquitetura multizona. |
5.20 |
Plano de emergência para danos no sistema é obrigatório. Ativação proporcional à gravidade (prioridade para recalls). |
|
|
A avaliação é compatível se cada instância SLB usar arquitetura multizona. |
5.20 |
Desenvolva plano de emergência para danos sistêmicos. Ative-o conforme a urgência (dados de recall prioritários). |
|
|
A conformidade é verificada quando cada instância ALB usa arquitetura multizona. Implantação em zona única pode causar interrupção em caso de falha. |
5.20 |
Plano de emergência para danos é obrigatório. Ativação baseada na criticidade (recalls prioritários). |
|
|
A avaliação é compatível se cada instância MongoDB usar arquitetura multizona. |
5.20 |
Tenha plano de emergência para danos no sistema. Ative-o conforme a urgência (informações de recall imediatas). |
|
|
Grupo de Auto Scaling deve estar associado a pelo menos dois vSwitches |
A conformidade é atingida quando cada grupo de dimensionamento está associado a pelo menos dois vSwitches. |
5.20 |
Plano de emergência para danos sistêmicos é obrigatório. Ativação proporcional à gravidade (prioridade para recalls). |
|
A avaliação é compatível se múltiplas zonas estiverem configuradas para cada serviço de endpoint. |
5.20 |
Desenvolva plano de emergência para danos. Ative-o conforme a urgência (dados de recall prioritários). |
|
|
A conformidade é verificada quando o cluster standby quente está habilitado em cada cluster PolarDB, com dados distribuídos em múltiplas zonas. |
5.20 |
Plano de emergência para danos no sistema é obrigatório. Ativação baseada na criticidade (recalls imediatos). |
|
|
A avaliação é compatível se os recursos associados aos grupos vServer de cada instância SLB estiverem distribuídos em múltiplas zonas. Aplica-se apenas a grupos vServer com recursos associados. |
5.20 |
Tenha plano de emergência para danos sistêmicos. Ative-o conforme a urgência (informações de recall prioritárias). |
|
|
Grupos de servidores ALB devem ter recursos distribuídos em múltiplas zonas |
A conformidade é atingida quando os recursos associados aos grupos de servidores de cada instância ALB estão distribuídos em múltiplas zonas. Aplica-se apenas a grupos de servidores com recursos associados. |
5.20 |
Plano de emergência para danos no sistema é obrigatório. Ativação proporcional à gravidade (prioridade para recalls). |