Modelo de controlo de acessos

O controlo de acesso Lakewatch é governado pelo Unity Catalog. Os recursos Lakewatch são objetos protegidos do Catálogo Unity que estão localizados num catálogo e esquema que escolhes, e concedes acesso a eles usando privilégios do Catálogo Unity. O acesso é herdado para baixo na hierarquia do Catálogo Unity, por isso uma permissão sobre um catálogo ou esquema aplica-se aos recursos Lakewatch abaixo dele.

Principals

O acesso é concedido a principais: utilizadores individuais, identidades de serviço (identificadas pelo nome ou applicationId) e grupos. O Lakewatch não requer papéis ou grupos pré-definidos, e pode usar qualquer identidade que o Unity Catalog suporte. Para uma configuração recomendada baseada em equipas que mapeia grupos para funções de segurança, consulte Configurar o controlo de acesso.

Recursos do Lakewatch como objetos protegíveis do Unity Catalog

Estes recursos do Lakewatch são protegíveis do Unity Catalog e existem num catálogo e esquema que escolher:

• Fontes de dados
• Regras de deteção

Organiza-os como qualquer outro dado do Catálogo Unity, por exemplo, um catálogo por ambiente (desenvolvimento/staging/produção) e um esquema por equipa. Consulte Modelos de implementação para padrões sugeridos.

Dois grupos de recursos são governados pelo Unity Catalog, mas tratados de forma diferente:

• As consultas são geridas através da aplicação Lakewatch, usando os seus próprios níveis de permissões em vez dos privilégios que concede sobre fontes de dados e regras de deteção.
• Sinais e alertassão derivados das regras de deteção: uma regra produz sinais, que são agrupados em alertas. Não são objetos protegíveis separados, por isso não concede permissões diretamente sobre elas. Os privilégios de segurança de dados (READ_SECURITY_DATA e UPDATE_SECURITY_DATA) na regra principal ou na origem de dados controlam o acesso aos mesmos (ver Herança).

Ambientes de trabalho e pastas

O Lakehouse regista os catálogos e esquemas do Unity Catalog que guardam os seus recursos como ambientes e pastas:

• Um ambiente é um catálogo registado no Lakewatch (o âmbito de topo dos seus recursos). Um ambiente está disponível apenas a partir do espaço de trabalho ao qual o seu catálogo está vinculado (ver associação entre espaço de trabalho e catálogo).
• Uma folder é um esquema registado junto da Lakewatch nesse catálogo. As fontes de dados e as regras de deteção vivem em pastas, e os privilégios que concede numa pasta aplicam-se a todos os recursos que ela contém.

Ambientes e pastas são uma vista sobre a organização catálogo por ambiente, esquema por equipa descrita nos modelos de implementação; não alteram a forma como o acesso é concedido. Permissões de pasta são concessões do Catálogo Unity no esquema de apoio, pelo que Privilégios e Herança aplicam-se inalterados.

Privilégios

Pode conceder acesso com privilégios do Catálogo Unity num catálogo, esquema ou recurso individual. Lakewatch define privilégios para ler a configuração de um recurso, gerir o recurso, gerir o seu acesso e ler ou atualizar os dados de segurança (sinais e alertas) que este produz. Para a lista completa por tipo de recurso e o que cada privilégio permite, veja Funções e capacidades.

Para criar um recurso, um principal precisa de ter USE CATALOG no catálogo e USE SCHEMA no esquema, além do privilégio de criar nesse esquema ou catálogo: CREATE_DATASOURCE para uma fonte de dados ou CREATE_RULE para uma regra de deteção. USE CATALOG e USE SCHEMA são privilégios de percurso: por si só permitem que um principal aceda ao catálogo e ao esquema, mas não concedem a capacidade de visualizar um recurso (que requer READ_METADATA) ou de criar um.

Como cada recurso Lakewatch é um objeto protegível do Unity Catalog, qualquer acesso a um deles (incluindo simplesmente visualizá-lo) requer USE CATALOG no seu catálogo e USE SCHEMA no seu esquema, além do privilégio para a ação em si. O Unity Catalog aplica esta regra a todos os objetos que governa, como uma tabela, por isso conceder a alguém acesso de visualização a uma fonte de dados ou regra de deteção (READ_METADATA) também significa conceder-lhe USE CATALOG e USE SCHEMA, mesmo que esses dois privilégios isoladamente não revelem o recurso.

Inheritance

O acesso desce pela hierarquia do Catálogo Unity: catálogo → esquema → recurso. Um privilégio concedido num catálogo ou esquema aplica-se a todos os recursos Lakewatch abaixo dele, pelo que pode conceder de forma ampla ao nível do catálogo ou esquema em vez de recurso por recurso.

A configuração recomendada concede a cada grupo os privilégios ao nível do catálogo, por isso aplicam-se a todos os esquemas e recursos do catálogo. Para delimitar um grupo de forma mais restrita, conceda os mesmos privilégios ao nível do esquema.

Sinais e alertas são artefactos derivados, sem permissões próprias. O acesso é herdado da regra de deteção do pai ou da fonte de dados, mas através de um privilégio separado da leitura da configuração do pai:

• READ_METADATA numa Regra de Deteção ou Origem de Dados permite-te ler esse recurso e a sua configuração. Por si só, não concede acesso aos sinais e alertas que o recurso produz.
• Visualizar esses sinais e alertas requer READ_SECURITY_DATA sobre o recurso pai (um privilégio separado de READ_METADATA).
• Atualizar um alerta depende do privilégio UPDATE_SECURITY_DATA no recurso pai. Os sinais são imutáveis.

Propriedade

A entidade principal responsável que cria um recurso Lakewatch torna-se o seu proprietário, com controlo total sobre o recurso, incluindo a gestão do seu acesso. A propriedade pode ser transferida e o acesso pode ser partilhado de forma mais ampla, concedendo privilégios a outras entidades principais.

Settings

As definições do Lakewatch estão vinculadas a um catálogo e aplicam-se a todos os recursos do Lakewatch que nele existem. Uma entidade com MANAGE no catálogo pode alterar as definições desse catálogo.

Integração e administração

Um utilizador que tenha USE CATALOG num catálogo, USE SCHEMA num esquema e o privilégio de criação relevante (CREATE_DATASOURCE ou CREATE_RULE) pode criar recursos Lakewatch aí e é dono do que cria. No catálogo predefinido do workspace, os utilizadores do workspace têm USE CATALOG e USE SCHEMA por defeito, mas CREATE_DATASOURCE e CREATE_RULE não são concedidos por defeito, pelo que um utilizador deve receber o privilégio de criação relevante antes de poder criar recursos Lakewatch aí. Para configurar o Lakewatch para uma equipa, siga Configurar o controlo de acesso, que cria os grupos, um principal de serviço run-as e as permissões necessárias. Pode delegar a gestão de um conjunto de recursos concedendo MANAGE no catálogo ou no esquema.

O controlo de acesso é principalmente baseado no proprietário do recurso: uma verificação de privilégios é satisfeita por uma concessão explícita ou pela posse do recurso, e a Lakewatch não tem um mecanismo de substituição administrativa separado. Administradores de contas e administradores da metastore ainda podem assumir a propriedade ou conceder-se a si próprios MANAGE através dos privilégios de administrador do Unity Catalog. Se o proprietário de um recurso deixar de estar disponível (por exemplo, a pessoa sair ou um principal de serviço for eliminado) e nenhum outro principal detiver MANAGE, o acesso pode ser difícil de recuperar, por isso a Databricks recomenda possuir recursos de produção com um grupo. Consulte modelos de implantação.

Tarefas agendadas e o principal run-as

Cada fonte de dados e regra de deteção regista um run-as principal. Escolhe-o quando crias o recurso (a tua própria identidade, ou um principal de serviço que tens permissão para usar), e só alguém com MANAGE no recurso pode alterá-lo. Os pipelines de ingestão e deteção agendados para o recurso executam-se como este principal, pelo que deve ser concedido acesso às tabelas referenciadas pela fonte de dados ou regra de deteção. Para criar um principal de serviço para este propósito e conceder-lhe o acesso de que os trabalhos agendados necessitam, veja Configurar controlo de acesso.