Ataques maliciosos ou tráfego fraudulento direcionado aos seus buckets podem causar picos repentinos de largura de banda e transferência de dados, resultando em cobranças inesperadamente altas. Siga estas práticas recomendadas de segurança para reduzir o risco de incidentes onerosos.
Estas práticas recomendadas são orientações gerais, não uma solução de segurança abrangente. Elas podem não ser adequadas ao seu ambiente ou às suas necessidades específicas. Incorpore-as a uma estratégia de segurança mais ampla e mantenha vigilância constante sobre a proteção de dados e conteúdo.
Riscos de perdas financeiras significativas
Ataques maliciosos ou tráfego fraudulento no seu bucket podem gerar os seguintes riscos financeiros:
Cobranças elevadas: ataques maliciosos consomem a largura de banda do Object Storage Service (OSS), e você é responsável pelos custos resultantes.
Cobranças que excedem o saldo da sua conta: o OSS opera no modelo de pagamento conforme o uso, e os valores das faturas são influenciados por fatores como ciclos de faturamento e atrasos no processamento. Por isso, o serviço não pode ser suspenso imediatamente quando o saldo da sua conta chega a zero. Isso pode resultar em um pagamento em atraso . Se o seu bucket for alvo de um ataque malicioso ou sofrer roubo de tráfego, você poderá incorrer em cobranças elevadas. O risco associado é que o valor faturado frequentemente excederá o saldo da sua conta.
Bloqueie o acesso público
O OSS permite acesso público por meio de políticas de bucket e ACLs, o que significa que qualquer pessoa pode acessar seus recursos sem autenticação. Isso cria riscos de vazamento de dados e custos elevados de tráfego decorrentes de atividade maliciosa. Para mitigar esses riscos, o OSS oferece o recurso Block Public Access com um clique, disponível nos níveis global, de bucket, de access point ou de access point do Function Compute. Após a ativação, o Block Public Access sobrescreve as permissões públicas existentes e impede a criação de novas, protegendo seus dados contra exposição pública. Para obter mais informações, consulte Block Public Access.
Acesse recursos do OSS pelo PrivateLink
O PrivateLink estabelece uma conexão privada e segura entre a sua VPC e o OSS, evitando os riscos de segurança do acesso pela internet pública. Uma conexão privada reforça a segurança dos dados e reduz o risco de custos excessivos gerados por tráfego malicioso. Os benefícios incluem:
Isolamento: o PrivateLink garante que seus recursos do OSS sejam acessíveis apenas de dentro da sua VPC autorizada, prevenindo ataques baseados na internet.
Controle de permissões: um endpoint de VPC permite aplicar controles de acesso granulares, como restringir o acesso a endereços IP ou sub-redes específicos ou impor regras específicas de grupo de segurança.
Monitoramento de tráfego: serviços implantados na sua VPC possibilitam melhor monitoramento e gerenciamento do tráfego de rede, o que permite detectar anomalias rapidamente e prevenir acessos maliciosos.
Para obter mais informações, consulte Access OSS through PrivateLink.
Defina as permissões de ACL como privadas
Não defina a lista de controle de acesso (ACL) de um bucket ou objeto como public-read ou public-read-write, a menos que qualquer pessoa precise ler ou gravar nos seus recursos do OSS. As seguintes permissões se aplicam ao conceder acesso público:
-
public-read-write: qualquer pessoa pode ler e gravar objetos no bucket.
AvisoEssa configuração permite que qualquer usuário na internet acesse seus objetos e faça upload de novos objetos para o bucket. Isso pode levar a exfiltração de dados, picos inesperados de custos e possíveis problemas legais caso conteúdo malicioso ou ilegal seja carregado. A menos que seja absolutamente necessário para um caso de uso específico, recomendamos fortemente não conceder permissões
public-read-write. -
public-read: somente o proprietário do bucket pode gravar objetos, mas qualquer pessoa pode ler os objetos.
AvisoEssa configuração permite que qualquer usuário na internet acesse seus objetos, o que pode resultar em exfiltração de dados e picos inesperados de custos. Use essa permissão com cautela.
Para evitar esses riscos de segurança, recomendamos fortemente definir a ACL dos seus buckets e objetos como private. Antes de alterar uma ACL para private, verifique se a alteração não afeta suas aplicações ou serviços.
Para instruções detalhadas, consulte Set bucket ACL e Set object ACL.
Configure regras de alerta no CloudMonitor
Crie regras de alerta no CloudMonitor para monitorar o uso e o status dos seus recursos do OSS. Quando uma métrica exceder um limiar predefinido, o CloudMonitor envia um alerta para que você identifique e resolva anomalias rapidamente.
Por exemplo, você pode configurar uma regra de alerta para um bucket que dispare quando uma métrica — como tráfego público de entrada ou saída — atingir 100 MB ou mais em um minuto. As informações do alerta são então gravadas em um Logstore especificado no Simple Log Service.
O exemplo a seguir mostra como configurar uma regra de alerta disparada quando o tráfego público de entrada atinge 100 MB ou mais:
Na caixa de diálogo Create Alert Rule, defina Product como Object Storage Service (OSS), Resource Range como Instance e Associate Resources como examplebucket. Defina Rule Name como alert e a condição de alerta como (Bucket)Public Inbound Traffic ≥ 100 Mbytes por um período consecutivo. Defina Mute For como 24 hours e Effective Period de 00:00 a 23:59. Selecione group1 em Contact Group. Em Advanced Settings, ative Simple Log Service. Em Region, selecione China (Hangzhou) e configure os campos ProjectName e Logstore correspondentes. Mantenha as demais opções, como Auto Scaling, Message Service (MNS)—topic e Function Compute, desativadas. Em Method to Process No Data, selecione Do not process.
É possível configurar regras de alerta para um bucket específico ou para todos os recursos do OSS na sua conta Alibaba Cloud. Para obter mais informações, consulte Create an alert rule.
Configure a proteção contra hotlink
Configure regras de acesso baseadas em Referer no OSS para impedir que referenciadores não autorizados acessem seus objetos. Isso bloqueia o hotlinking de outros sites e protege você contra custos desnecessários de tráfego.
Quando um navegador envia uma requisição ao OSS, o cabeçalho da requisição inclui um Referer que indica a origem. Se a proteção contra hotlink estiver configurada, o OSS avalia o Referer com base nas regras configuradas para permitir ou negar a requisição:
Se o Referer da requisição corresponder a uma entrada na lista de bloqueios ou não corresponder a nenhuma entrada na lista de permissões, o OSS nega a requisição.
Se o Referer da requisição corresponder a uma entrada na lista de permissões, o OSS permite a requisição.
Por exemplo, considere um bucket com uma lista de permissões de Referer contendo https://10.10.10.10.
O Usuário A incorpora uma imagem, test.jpg, armazenada no bucket no site
https://10.10.10.10. Quando um navegador solicita essa imagem, o cabeçalho da requisição incluihttps://10.10.10.10como Referer. Nesse caso, o OSS permite a requisição.O Usuário B faz hotlink da imagem test.jpg e a incorpora no site
https://192.168.0.0. Quando um navegador solicita essa imagem, o cabeçalho da requisição incluihttps://192.168.0.0como Referer. Nesse caso, o OSS nega a requisição.
Para obter mais informações, consulte Hotlink protection.
Configure o compartilhamento de recursos entre origens (CORS)
O compartilhamento de recursos entre origens (CORS) é um mecanismo padrão que permite aos servidores web controlar o acesso de diferentes origens para garantir transferências de dados entre origens de forma segura. Os navegadores aplicam uma política de mesma origem para isolar arquivos potencialmente maliciosos. Por padrão, o navegador bloqueia uma requisição quando código JavaScript de uma origem tenta acessar um recurso de uma origem diferente.
O OSS permite configurar regras de CORS para permitir ou negar requisições entre origens. Por exemplo, para permitir apenas requisições da origem www.aliyun.com com o método de requisição entre origens GET, configure a regra de CORS da seguinte forma:
Na caixa de diálogo Create CORS Rule, deixe Allowed Headers e Exposed Headers em branco. Defina Cache Timeout (Seconds) como 0 e deixe Vary: Origin desmarcado.
Para obter mais informações, consulte Configure CORS.
Evite prefixos sequenciais nos nomes de objetos
Ao fazer upload de um grande número de objetos, o uso de prefixos previsíveis e sequenciais — como timestamps, sequências alfabéticas, datas ou IDs numéricos — permite que invasores adivinhem e recuperem todos os seus objetos iterando pelo padrão de nomenclatura. Isso pode resultar em vazamento de dados. Adicione um prefixo de hash hexadecimal aleatório aos nomes dos seus objetos ou inverta os caracteres do nome para reduzir significativamente o risco de enumeração de nomes de objetos. Para obter mais informações, consulte Data security.