Modelo de controle de acesso

O controle de acesso Lakewatch é regido pelo Unity Catalog. Os recursos do Lakewatch são objetos protegidos do Unity Catalog que ficam em um catálogo e esquema que você escolhe, e você concede acesso a eles usando privilégios do Unity Catalog. O acesso é herdado para baixo na hierarquia do Catálogo Unity, então uma permissão concedida em um catálogo ou esquema se aplica aos recursos do Lakewatch abaixo dele.

Principals

O acesso é concedido às entidades de segurança: usuários individuais, entidades de serviço (identificadas pelo nome ou applicationId) e grupos. O Lakewatch não exige papéis ou grupos predefinidos, e você pode usar qualquer identidade que o Unity Catalog suporte. Para uma configuração recomendada baseada em equipe que mapeia grupos para funções de segurança, veja Configurar controle de acesso.

Recursos do Lakewatch como securables do Catálogo do Unity

Esses recursos do Lakewatch são objetos protegíveis do Unity Catalog e ficam em um catálogo e esquema que você escolhe:

• Fontes de dados
• Regras de detecção

Você os organiza como qualquer outro dado do Catálogo Unity, por exemplo, um catálogo por ambiente (desenvolvimento/staging/produção) e um esquema por equipe. Veja Modelos de implantação para padrões sugeridos.

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

• As consultas são gerenciadas pelo aplicativo Lakewatch, usando seus próprios níveis de permissões, em vez dos privilégios que você concede sobre fontes de dados e regras de detecção.
• Sinais e alertas são derivados de regras de detecção: uma regra produz sinais, que são agrupados em alertas. Eles não são securables separados, então você não concede permissões sobre eles diretamente. Os privilégios de security-data (READ_SECURITY_DATA e UPDATE_SECURITY_DATA) na regra pai ou fonte de dados controlam o acesso a eles (veja Herança).

Ambientes e pastas

O Lakewatch registra os catálogos e esquemas do Unity Catalog que armazenam seus recursos como ambientes e pastas:

• Um environment é um catálogo registrado no Lakewatch (o escopo de alto nível para seus recursos). Um ambiente está disponível apenas a partir do espaço de trabalho ao qual seu catálogo está vinculado (veja Vinculação de catálogo de workspace).
• Uma pasta é um esquema registrado no Lakewatch nesse catálogo. Fontes de dados e regras de detecção ficam em pastas, e os privilégios que você concede em uma pasta se aplicam a todos os recursos que ela contém.

Ambientes e pastas são uma visão sobre a organização catálogo-por-ambiente, esquema-por-equipe descrita nos modelos de implantação; eles não mudam a forma como o acesso é concedido. Permissões de pasta são concessões do Catálogo Unity no esquema de apoio, então Privilégios e Herança se aplicam sem alterações.

Privilégios

Você concede acesso com privilégios do Catálogo Unity em um catálogo, esquema ou recurso individual. Lakewatch define privilégios para ler a configuração de um recurso, gerenciar o recurso, gerenciar seu acesso e ler ou atualizar os dados de segurança (sinais e alertas) que ele 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 USE CATALOG no catálogo e de USE SCHEMA no esquema, além do privilégio de criação nesse esquema ou catálogo: CREATE_DATASOURCE para uma fonte de dados ou CREATE_RULE para uma regra de detecção. USE CATALOG e USE SCHEMA são privilégios de travessia: por si só, permitem que um principal acesse o catálogo e o esquema, mas não concedem a capacidade de visualizar um recurso (que requer READ_METADATA) ou de criar um.

Como todo recurso do Lakewatch é um objeto protegível do Unity Catalog, qualquer acesso a um deles (incluindo simplesmente visualizá-lo) requer USE CATALOG em seu catálogo e USE SCHEMA em seu esquema, além do privilégio para a ação em si. O Unity Catalog aplica essa regra a todo objeto que ele governa, como uma tabela, então conceder a alguém acesso de visualização a uma fonte de dados ou regra de detecção (READ_METADATA) também significa conceder a essa pessoa 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 em um catálogo ou esquema se aplica a todo recurso Lakewatch abaixo dele, então você pode conceder amplamente no nível de catálogo ou esquema, em vez de recurso por recurso.

A configuração recomendada concede privilégios a cada grupo no nível do catálogo, então eles se aplicam a todos os esquemas e recursos do catálogo. Para restringir mais o escopo de um grupo, conceda os mesmos privilégios no nível do esquema.

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

• READ_METADATA em uma regra de detecção ou fonte de dados permite que você leia esse recurso e a configuração dele. Ele não concede, por si só, acesso aos sinais e alertas que o recurso produz.
• Visualizar esses sinais e alertas requer READ_SECURITY_DATA no recurso pai (um privilégio separado de READ_METADATA).
• A atualização de um alerta depende do privilégio UPDATE_SECURITY_DATA no recurso pai. Os sinais são imutáveis.

Propriedade

A entidade que cria um recurso do Lakewatch torna-se seu proprietário, com controle total sobre o recurso, incluindo o gerenciamento de seu acesso. A propriedade pode ser transferida, e o acesso pode ser compartilhado de maneira mais ampla, concedendo privilégios a outras entidades de segurança.

Settings

As configurações do Lakewatch estão vinculadas a um catálogo e se aplicam a todos os recursos do Lakewatch nele. Um principal com MANAGE no catálogo pode alterar as configurações desse catálogo.

Integração e administração

Um usuário que tem USE CATALOG em um catálogo, USE SCHEMA em um esquema e o privilégio de criação relevante (CREATE_DATASOURCE ou CREATE_RULE) pode criar recursos do Lakewatch lá e é dono do que cria. No catálogo padrão do workspace, os usuários do workspace têm USE CATALOG e USE SCHEMA por padrão, mas CREATE_DATASOURCE e CREATE_RULE não são concedidos por padrão, então um usuário deve receber o privilégio de criação relevante antes de poder criar recursos do Lakewatch ali. Para configurar o Lakewatch para uma equipe, siga o Configurar controle de acesso, que cria os grupos, um principal de serviço run-as e as permissões necessárias. Você pode delegar o gerenciamento de um conjunto de recursos concedendo MANAGE no catálogo ou no esquema.

O controle de acesso é principalmente baseado no proprietário: uma verificação de privilégio é satisfeita por uma concessão explícita ou pela propriedade do recurso, e o Lakewatch não possui uma substituição de administrador separada própria. Administradores de conta e administradores da metastore ainda podem assumir a propriedade ou conceder a si mesmos MANAGE os privilégios de administrador do Unity Catalog. Se o proprietário de um recurso não estiver mais disponível (por exemplo, se a pessoa sair ou se uma entidade de serviço for excluída) e nenhuma outra entidade tiver MANAGE, o acesso poderá ser difícil de recuperar, portanto, o Databricks recomenda que recursos de produção sejam de propriedade de um grupo. Veja Modelos de implantação.

Tarefas agendadas e a entidade de execução

Cada fonte de dados e regra de detecção registra uma entidade de execução como. Você escolhe isso quando cria o recurso (sua própria identidade ou uma entidade de serviço que você tem permissão para usar), e só alguém com MANAGE no recurso pode alterá-lo. Os pipelines de ingestão e detecção agendados para o recurso são executados com essa identidade, portanto, ela deve ter acesso às tabelas referenciadas pela fonte de dados ou regra de detecção. Para criar um principal de serviço para esse propósito e conceder a ele o acesso que seus trabalhos agendados necessitam, veja Configurar controle de acesso.