Os Assembly IDs são seguros?
A Transloadit usa UUIDv4 sem hífens para gerar esses IDs aleatoriamente. Adivinhar, ou gerar, um UUID que coincida com um dos nossos seria tão provável quanto gerar uma colisão. Isso é tão improvável que não é considerado um vetor de ataque viável.
Como mantemos cerca de 5.000.000 Assemblies em armazenamento ativo a qualquer momento, as chances são, reconhecidamente, 5.000.000 vezes maiores de gerar uma colisão. Identificadores UUIDv4 aleatórios ainda tornam a adivinhação de um Assembly ID ativo computacionalmente inviável. Os limites de taxa oferecem uma defesa adicional, mas a cota de criação de Assembly não é um limite para consultas de Assembly Status. Consideramos que a adivinhação aleatória está longe de ser um vetor de ataque viável.
Para arquivos, a janela fica ainda menor, porque nós os removemos após 24 horas. Alguns motivos pelos quais optamos por fazer isso estão descritos aqui.
Além da possibilidade de adivinhar arquivos ou URLs de Assembly, é claro que existe a preocupação de que esses endereços vazem de alguma forma. Consideramos o ID de Assembly e a URL do arquivo como informações privadas. Eles são um segredo compartilhado entre a Transloadit, nosso cliente e, dependendo da sua integração, o usuário final específico para o qual o cliente está fornecendo os arquivos e executando a Assembly em seu nome.
Essa comunicação entre essas partes acontece por HTTPS, para o qual temos nota A+ no SSL Labs (English) em todos os aspectos. Se o HTTPS for usado na integração com a Transloadit e com o usuário final em todas as requisições envolvidas, as URLs das Assemblies e dos arquivos não podem vazar para além dessas partes confiáveis a ponto de se tornarem um vetor de ataque viável.
Depois, há a Transloadit para se analisar como parte confiável. Nossa política é que apenas os membros de confiança da nossa equipe principal têm acesso a esses arquivos para fins de depuração. Recebemos milhões de arquivos todos os dias e, para nós, eles são apenas UUIDs até que um cliente nos peça para olhar mais de perto.
Executamos nossos processos como usuários sem privilégios e fornecemos a eles as credenciais de que precisam. Um processo comprometido pode expor as credenciais que recebe sem acesso root. O acesso aos dados criptografados depende das permissões das credenciais roubadas e do acesso às chaves de descriptografia correspondentes. A criptografia em repouso não protege os dados de um atacante que consiga usar um caminho de leitura autorizado. Limitar credenciais e proteger processos continuam sendo práticas importantes, e nenhum sistema pode oferecer 100% de garantia de segurança.