Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Atualizado em : Mar 29, 2022
NÃO ENTROU NA EDIÇÃO ATUAL
Este blip não está na edição atual do Radar. Se esteve em uma das últimas edições, é provável que ainda seja relevante. Se o blip for mais antigo, pode não ser mais relevante e nossa avaliação pode ser diferente hoje. Infelizmente, não conseguimos revisar continuamente todos os blips de edições anteriores do Radar. Saiba mais
Mar 2022
Evite ? Prossiga com cautela.

Continuamos a perceber dados de produção em ambientes de teste como uma área de preocupação. Em primeiro lugar, muitos exemplos dessa prática resultaram em danos à reputação, por exemplo, quando um alerta incorreto foi enviado de um sistema de teste para toda uma base de clientes. Em segundo lugar, o nível de segurança, especificamente em torno da proteção de dados privados, tende a ser menor para sistemas de teste. Não adianta ter controles elaborados sobre o acesso aos dados de produção se esses dados forem copiados para um banco de dados de teste que pode ser acessado por todas as pessoas desenvolvedoras e QAs. Embora seja possível ofuscar os dados, isso tende a ser aplicado apenas a campos específicos, por exemplo, números de cartão de crédito. Por fim, copiar dados de produção para sistemas de teste pode violar as leis de privacidade, por exemplo, quando os sistemas de teste são hospedados em ou acessados ​​de um país ou região diferente. Este último cenário é especialmente problemático com implantações de nuvem complexas. Dados falsos são uma abordagem mais segura e existem ferramentas que ajudam a criá-los. Reconhecemos que existem razões para que elementos específicos dos dados de produção sejam copiados, por exemplo, para reprodução de bugs ou treinamento de modelos de ML específicos. Aqui, nosso conselho é proceder com cautela

Oct 2021
Evite ? Prossiga com cautela.

Continuamos a perceber dados de produção em ambientes de teste como uma área de preocupação. Em primeiro lugar, muitos exemplos dessa prática resultaram em danos à reputação, por exemplo, quando um alerta incorreto foi enviado de um sistema de teste para toda uma base de clientes. Em segundo lugar, o nível de segurança, especificamente em torno da proteção de dados privados, tende a ser menor para sistemas de teste. Não adianta ter controles elaborados sobre o acesso aos dados de produção se esses dados forem copiados para um banco de dados de teste que pode ser acessado por todas as pessoas desenvolvedoras e QAs. Embora seja possível ofuscar os dados, isso tende a ser aplicado apenas a campos específicos, por exemplo, números de cartão de crédito. Por fim, copiar dados de produção para sistemas de teste pode violar as leis de privacidade, por exemplo, quando os sistemas de teste são hospedados em ou acessados ​​de um país ou região diferente. Este último cenário é especialmente problemático com implantações de nuvem complexas. Dados falsos são uma abordagem mais segura e existem ferramentas que ajudam a criá-los. Reconhecemos que existem razões para que elementos específicos dos dados de produção sejam copiados, por exemplo, para reprodução de bugs ou treinamento de modelos de ML específicos. Aqui, nosso conselho é proceder com cautela.

Publicado : Oct 27, 2021

Baixar o Technology Radar Volume 27

English | Español | Português | 中文

Mantenha-se por dentro das tendências de tecnologia

 

Seja assinante

Visite nosso arquivo para acessar os volumes anteriores