Modelo de controle de acesso

info

Visualização

O Lakewatch está em Visualização privada. Para solicitar acesso, entre em contato com a equipe da sua account Databricks.

O controle de acesso ao Lakewatch é regido pelo Unity Catalog. Os recursos do Lakewatch são objetos protegíveis do Unity Catalog que residem em um catálogo e esquema que você escolhe, e você concede acesso a eles usando privilégios do Unity Catalog. O acesso é herdado na hierarquia do Unity Catalog, portanto, uma concessão em um catálogo ou esquema se aplica aos recursos do Lakewatch abaixo dele.

Principals

O acesso é concedido a principals: usuários individuais, Service Principal (identificadas por nome ou applicationId) e grupos. O Lakewatch não exige funções ou grupos predefinidos, e você pode usar qualquer identidade que o Unity Catalog ofereça suporte. Para uma configuração baseada em equipe recomendada que mapeia grupos para funções de segurança, consulte Configurar o controle de acesso.

Recursos do Lakewatch como securables do Unity Catalog

Esses recursos do Lakewatch são objetos protegíveis do Unity Catalog e residem sob um catálogo e um esquema que você escolher:

• Fontes de dados
• Regras de detecção

Você os organiza como quaisquer outros dados do Unity Catalog, por exemplo, com um catálogo por ambiente (dev/staging/prod) e um esquema por equipe. Consulte Modelos de implantação para ver padrões sugeridos.

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

• As consultas são gerenciadas por meio do aplicativo Lakewatch, usando seus próprios níveis de permissão em vez dos privilégios que você concede nas fontes de dados e nas regras de detecção.
• Sinais e alertas são derivados de regras de detecção: uma regra gera sinais, que são agrupados em alertas. Eles não são protegíveis separadamente, portanto você não concede direitos sobre eles diretamente. Os privilégios de segurança de dados (READ_SECURITY_DATA e UPDATE_SECURITY_DATA) na regra pai ou na fonte de dados controlam o acesso a eles (consulte Herança).

Ambientes e pastas

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

• Um ambiente é um catálogo registrado no Lakewatch (o escopo de nível superior para seus recursos). Um ambiente só está disponível no workspace ao qual seu catálogo está vinculado (consulte Vinculação de catálogo de workspace).
• Uma pasta é um esquema registrado no Lakewatch sob esse catálogo. As fontes de dados e as regras de detecção residem em pastas, e os privilégios concedidos em uma pasta se aplicam a todos os recursos nela contidos.

Ambientes e pastas são uma view da organização de um catálogo por ambiente e um esquema por equipe descrita em Modelos de implantação; eles não alteram a forma como o acesso é concedido. As permissões de pasta são concessões do Unity Catalog no esquema de suporte, portanto, Privilégios e Herança se aplicam sem alterações.

Privilégios

Você concede acesso com privilégios do Unity Catalog em um catálogo, esquema ou recurso individual. O 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 obter a lista completa por tipo de recurso e o que cada privilégio permite, consulte Funções e capacidades.

Para criar um recurso, um principal precisa de USE CATALOG no catálogo e 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 transversal: por si só, eles permitem que um principal alcance o catálogo e o esquema, mas não concedem a capacidade de view um recurso (que requer READ_METADATA) ou de criar um.

Como cada recurso do Lakewatch é um objeto seguro do Unity Catalog, qualquer acesso a um (incluindo simplesmente visualizá-lo) requer USE CATALOG em seu catálogo e USE SCHEMA em seu esquema, além do privilégio para a própria ação. O Unity Catalog aplica esta regra a todos os objetos que ele governa, como uma tabela, portanto, conceder a alguém acesso de view a uma fonte de dados ou regra de detecção (READ_METADATA) também significa conceder a eles USE CATALOG e USE SCHEMA, embora esses dois privilégios por si só não revelem o recurso.

Herança

O acesso flui pela hierarquia do Unity Catalog: catálogo → esquema → recurso . Um privilégio concedido em um catálogo ou esquema aplica-se a todos os recursos do Lakewatch abaixo dele, para que você possa conceder amplamente no nível de catálogo ou esquema em vez de recurso por recurso.

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

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

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

Propriedade

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

Configurações

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

Integração e administração

Um usuário que possui 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 Lakewatch lá e é proprietário do que cria. No catálogo padrão do workspace, os usuários do workspace possuem USE CATALOG e USE SCHEMA por default, mas CREATE_DATASOURCE e CREATE_RULE não são concedidos por default, portanto, um usuário deve ter o privilégio de criação relevante concedido antes que possa criar recursos Lakewatch lá. Para configurar o Lakewatch para uma equipe, siga Configurar o controle de acesso, que cria os grupos, um service principal de execução e as concessões necessárias. Você pode delegar o gerenciamento de um conjunto de recursos concedendo MANAGE no catálogo ou esquema.

O controle de acesso é baseado principalmente no proprietário : uma verificação de privilégio é satisfeita por uma concessão explícita ou por ser proprietário do recurso, e o Lakewatch não tem uma substituição de administrador separada própria. Os administradores de contas e administradores do metastore ainda podem assumir a propriedade ou conceder a si mesmos MANAGE por meio dos privilégios de administrador do Unity Catalog. Se o proprietário de um recurso for perdido (por exemplo, a pessoa sai ou um Service Principal é excluído) e nenhum outro principal mantiver MANAGE, o acesso poderá ser difícil de recuperar; portanto, a Databricks recomenda possuir recursos de produção com um grupo. Consulte Modelos de implantação.

Jobs agendados e principal de execução

Cada fonte de dados e regra de detecção registra um principal de execução . Você o escolhe quando cria o recurso ( sua própria identidade ou um service principal que você tem permissão para usar), e somente alguém com MANAGE no recurso pode alterá-lo. Os pipelines de ingestão e detecção agendados para o recurso estão em execução como este principal, por isso ele deve receber acesso às tabelas às quais a fonte de dados ou a regra de detecção faz referência. Para criar um service principal para este propósito e conceder a ele o acesso que seus jobs agendados precisam, consulte Configurar o controle de acesso.