Gerenciamento de Acesso a Dados no AWS S3: Uma Abordagem Automatizada
Há algum tempo, quando os servidores Unix com grandes sistemas de arquivos eram comuns, as empresas definiam regras complexas para gerenciar pastas e controlar o acesso a diferentes diretórios por diferentes usuários.
Normalmente, a infraestrutura de uma organização atende a vários grupos de usuários com necessidades, restrições de confidencialidade ou requisitos de conteúdo distintos. Em empresas globais, isso pode até significar a separação de conteúdo por localização geográfica, dividindo usuários por país.
Outros exemplos típicos incluem:
- Isolamento de dados entre ambientes de desenvolvimento, teste e produção.
- Restrição de conteúdo de vendas a um público específico.
- Controle de acesso a conteúdo legislativo específico para cada país.
- Limitação de acesso a dados de projetos a grupos selecionados.
A lista de exemplos é potencialmente infinita. A necessidade de gerenciar o acesso a arquivos e dados para todos os usuários da plataforma é universal.
Em soluções locais, essa tarefa era rotineira. O administrador configurava regras, usava ferramentas e mapeava usuários para grupos e, em seguida, grupos para pastas. O nível de acesso era definido como somente leitura ou leitura/gravação.
Com as plataformas de nuvem, como a AWS, espera-se que haja requisitos similares para restringir o acesso a conteúdo. No entanto, a solução deve ser diferente. Os arquivos não estão mais em servidores Unix, mas na nuvem (acessíveis a toda a organização ou até ao mundo), e o conteúdo está armazenado em *buckets* S3, não em pastas.
A seguir, apresento uma alternativa para abordar este problema, baseada em experiência prática.
Abordagem Simples, Mas Manual
Uma forma de resolver o problema sem automação é simples:
- Criar um *bucket* S3 para cada grupo de usuários.
- Definir permissões para que somente aquele grupo específico acesse o *bucket*.
Essa abordagem pode funcionar para soluções simples e rápidas. Contudo, há limitações.
Por padrão, uma conta AWS permite criar até 100 *buckets* S3. É possível aumentar esse limite para 1.000 solicitando um aumento através de um *ticket* à AWS. Se esses limites não forem um problema, você pode usar um *bucket* para cada grupo de usuários.
Problemas surgem quando grupos de usuários têm funções multifuncionais ou precisam acessar conteúdo de vários domínios simultaneamente. Por exemplo:
- Analistas de dados que avaliam informações de diversas áreas e regiões.
- Equipes de teste que compartilham serviços atendendo a várias equipes de desenvolvimento.
- Usuários que geram relatórios com dados de diferentes países.
A complexidade da orquestração do acesso aumenta conforme as necessidades das organizações e os casos de uso se multiplicam. Ferramentas adicionais e até um administrador dedicado podem ser necessários para gerenciar e atualizar as listas de permissões.
Como podemos alcançar o mesmo de forma mais organizada e automatizada?
Se a abordagem de um *bucket* por domínio não funciona, a solução envolve o compartilhamento de *buckets* entre grupos de usuários. Nesses casos, a lógica de atribuição de acesso deve ser flexível e dinâmica.
Uma solução é usar *tags* nos *buckets* S3. As *tags* são recomendadas para qualquer cenário (no mínimo para facilitar a categorização de custos). Elas podem ser alteradas a qualquer momento.
Ao construir toda a lógica com base nas *tags* do *bucket* e configurar o restante de acordo, a propriedade dinâmica é garantida. A finalidade do *bucket* pode ser redefinida alterando os valores das *tags*.
Que Tipo de *Tags* Usar?
Isso depende do seu caso de uso específico. Por exemplo:
- Separar *buckets* por tipo de ambiente (DEV, TEST, PROD). Usar uma *tag* como “ENV” com os respectivos valores.
- Separar por país. Criar uma *tag* “PAÍS” e atribuir o nome do país.
- Separar por departamento funcional (analistas, cientistas de dados). Usar uma *tag* “USER_TYPE”.
- Definir uma estrutura de pastas fixa para grupos de usuários. Utilizar uma *tag* que especifique diretórios como “data/import”, “data/processed”.
O ideal é definir *tags* que possam ser combinadas logicamente para formar uma estrutura de pastas completa no *bucket*.
Por exemplo, combinar as seguintes *tags* pode criar uma estrutura para diferentes usuários, de vários países, com pastas de importação predefinidas:
- /
/ / /
Ao alterar o valor de
Isso permite que o mesmo *bucket* seja usado por muitos usuários diferentes. Os *buckets* não suportam pastas diretamente, mas suportam “rótulos” que funcionam como subpastas. Os usuários precisam percorrer uma série de rótulos para acessar seus dados.
Após definir as *tags*, o próximo passo é criar políticas de *bucket* S3 que as usem.
Se as políticas utilizarem os nomes das *tags*, você estará criando “políticas dinâmicas”. Isso significa que a política se comportará de forma diferente para *buckets* com diferentes valores de *tag*.
Essa etapa envolve alguma codificação personalizada de políticas dinâmicas, mas você pode usar o editor de políticas da AWS.
Na política, você deve codificar os direitos de acesso (leitura, gravação) para cada *bucket*. A lógica lerá as *tags* e criará a estrutura de pastas com base nelas. Subpastas serão criadas com permissões de acesso adequadas.
A vantagem da política dinâmica é que você cria apenas uma e atribui a vários *buckets*. Ela se comportará de maneira diferente para cada um, mas sempre de acordo com a expectativa.
Esta é uma forma eficaz de gerenciar atribuições de direitos de acesso de forma centralizada para muitos *buckets*, que seguem modelos previamente definidos pela organização.
Automatize a Integração de Novas Entidades
Após definir políticas dinâmicas e atribuí-las aos *buckets*, os usuários podem utilizar os mesmos *buckets* sem o risco de acessar conteúdos em pastas para as quais não têm permissão.
Grupos de usuários com acesso mais amplo também se beneficiarão, pois todos os dados estarão no mesmo *bucket*.
O último passo é tornar a integração de novos usuários, *buckets* e *tags* o mais simples possível. Isso requer mais codificação, que não precisa ser complexa se o processo de integração seguir regras claras e diretas.
Isso pode ser tão simples quanto criar um *script* executável pela AWS CLI com parâmetros para integrar uma nova entidade à plataforma. Ou pode ser uma série de *scripts* CLI executados em ordem específica:
- create_new_bucket(
, , , , ..) - create_new_tag(
, , ) - update_existing_tag(
, , ) - create_user_group(
, , ) - etc.
Espero que tenha entendido. 😃
Uma Dica Profissional 👨💻
Uma dica adicional pode ser facilmente aplicada.
As políticas dinâmicas podem ser usadas não apenas para gerenciar acesso a pastas, mas também para atribuir direitos de serviços para *buckets* e grupos de usuários automaticamente!
Basta estender a lista de *tags* nos *buckets* e adicionar direitos de acesso de política dinâmica para usar serviços específicos para grupos de usuários.
Por exemplo, um grupo pode precisar de acesso a um servidor de banco de dados. Isso pode ser feito com políticas dinâmicas que gerenciam tarefas de *bucket*, principalmente se o acesso aos serviços for baseado em função. Basta adicionar ao código da política dinâmica uma parte que processará *tags* relacionadas ao banco de dados e atribuirá os privilégios necessários.
Desta forma, a integração de um novo grupo de usuários é feita por uma única política dinâmica. Ela pode ser reutilizada para muitos grupos diferentes, desde que sigam o mesmo modelo, embora não necessariamente os mesmos serviços.
Você também pode consultar estes Comandos S3 da AWS para gerenciar *buckets* e dados.