Modelo de mandato de controle de acesso (MAC): visão geral e aplicativos

Modelo de Controle de Acesso Obrigatório (MAC) - um método de controle de acesso com um conjunto fixo de permissões. Normalmente, esse MAC é usado em sistemas com altos requisitos de segurança e está ao serviço de várias agências e organizações policiais, associadas a segredos estatais ou oficiais.

Modelo MAC

O MAC, apesar de estar contido em muitos artigos e materiais, é frequentemente mencionado casualmente e na forma de um molho picante para algo como uma breve menção ao MLS no SELinux. Como muitos limitam sua amizade com o SELinux usando a receita " como desabilitar o SELinux ", o MAC geralmente também a honra. Portanto, primeiro brevemente sobre o MAC.

Se você estiver familiarizado com o modelo, poderá pular para a próxima seção.

Ideia principal

O modelo de segurança abstrato implementado no MAC clássico (como os policiais sabem) é o seguinte (figura clássica que ilustra o modelo de Bell-Lapadula ):


O modelo MAC é inerentemente uma implementação "eletrônica" de um fluxo de trabalho "secreto" em papel. O MAC tem os seguintes "atores":

• A hierarquia de níveis de acesso que são processados ​​no sistema (geralmente registrados no SO). Por conveniência, geralmente é especificado na forma de números não assinados (de 0 a um valor limitado pela implementação). Nesse caso, para comparar os níveis de acesso (maior / menor / igual), as operações aritméticas mais simples são usadas (igual, menor e mais).
• Objete com um nível de sigilo. Qualquer arquivo, diretório no sistema de arquivos, célula ou registro na tabela do banco de dados, tabela no banco de dados, o próprio banco de dados, pacote de rede etc. O objeto recebe qualquer valor da hierarquia de níveis de acesso. Para o objeto, é permitido aumentar o nível de sigilo (mude para um valor de nível superior ao atual). Uma diminuição no nível de sigilo não é categoricamente permitida (embora seja bastante viável com a ajuda de certos truques).
• Assunto com nível de acesso. O processo de um aplicativo ou uma sessão do usuário (essencialmente também o processo do aplicativo). O rótulo do nível de acesso é herdado do assunto por todos os objetos criados por este assunto.

O valor do nível de acesso do sujeito ou do nível de segurança do objeto é geralmente chamado de termo "nível obrigatório", "rótulo obrigatório" ou simplesmente "rótulo" (no STCSEC, esse termo é chamado de "nível hierárquico de classificação"). Simples, amplo e quase inequívoco.

A verificação de autorização é realizada a cada fato do acesso do sujeito ao objeto protegido pelo MAC. Nesse caso, o modelo de controle de acesso credencial geralmente é usado em conjunto com outros mecanismos de controle de acesso, por exemplo, o DAC (modelo UNIX e POSIX ACL). Nesse caso, o MAC é verificado por último. Primeiro, o acesso é verificado pelo DAC (como o menos seguro) e, em seguida, pelo MAC.

Ao verificar a elegibilidade do acesso do sujeito ao objeto de acordo com o modelo obrigatório, são possíveis as seguintes combinações:

1. O rótulo da credencial do assunto é igual ao rótulo da credencial do objeto. Nesse caso, o assunto pode ler e modificar o objeto.
2. O rótulo da credencial do sujeito é maior que o rótulo da credencial do objeto. O sujeito só pode ler o objeto: ele o vê, mas não pode mudá-lo.
3. O rótulo da credencial do assunto é menor que o rótulo da credencial do objeto. É formalmente permitido ao sujeito criar um objeto com uma marca de credencial mais alta (o chamado "aumenta o nível de sigilo do objeto"). Na prática, o sujeito não possui a capacidade técnica para executar esta operação (ele simplesmente "não vê" o objeto variável, por exemplo, um arquivo ou um diretório com arquivos).

Também no MAC existe uma “categoria” (na terminologia STCSEC, esse termo é chamado de “categorias não hierárquicas”). As categorias no MAC são opcionais. Na prática, a implementação de categorias MAC é usada para o controle de acesso "horizontal" entre diferentes departamentos da organização. Nesse caso, os funcionários, apesar de um nível obrigatório, só terão acesso às categorias de objetos às quais têm acesso, de acordo com seu rótulo.

Limitações e vulnerabilidades

O MAC tem suas limitações e recursos:

1. Os usuários do sistema não podem determinar independentemente o acesso de assuntos a objetos. De todo o arsenal de controle de acesso a objetos no MAC, há apenas um rótulo e uma categoria de credenciais associados a esse objeto. O gerenciamento do acesso de assuntos a objetos é realizado apenas pelos administradores.
2. Se o usuário quiser alterar o rótulo da credencial do objeto de quem é o autor, ele precisará ir para a sessão do rótulo de destino. Isso se deve ao fato de o usuário não poder especificar o rótulo à vontade, mas só pode passar o rótulo para o objeto "por herança". Ao mesmo tempo, o usuário pode trabalhar apenas em uma sessão com um rótulo de credencial.
3. Como o MAC é usado em conjunto com outros modelos de controle de acesso, surgem colisões: às vezes não é tão fácil descobrir em qual "camada" do acesso ao sistema de segurança é negada. É necessário um "ajuste fino" de todas as camadas de proteção.
4. Além das configurações de acesso através do kit de ferramentas MAC, é necessária uma política de segurança. Ele deve descrever o que significam os valores específicos das credenciais (isso está fora do MAC), quais objetos são protegidos, quais assuntos têm o direito de acessar. Sem uma regulamentação acordada, o MAC sozinho não fornecerá aprimoramento de segurança.
5. Usando o MAC em uma infraestrutura de rede distribuída. A abordagem tradicional para configurar o MAC é local, manualmente, com a ajuda de um administrador, de acordo com as instruções. Existem soluções que permitem implementar um armazenamento MAC gerenciado centralmente (como o ALD), mas eles têm características próprias e dificuldades de construção.

Projetando um aplicativo MAC

Apesar de todas as limitações do modelo, para quem trabalha com o setor público e, principalmente, com as agências policiais, a questão da criação de aplicativos com suporte a um modelo de controle de acesso obrigatório é mais relevante do que nunca. De repente, amanhã você terá que dar suporte ao MAC em seu produto?

À primeira vista, parece que o modelo é primitivo e sua implementação é tão simples quanto cinco centavos, mas há uma ressalva: o cliente que define o requisito para o uso do modelo de credencial tem em mente, antes de tudo, uma ferramenta de segurança da informação certificada. Informações verdadeiramente secretas, até segredos de estado, serão processadas nesse IP e será muito difícil certificar o próprio desenvolvimento no nível exigido. A saída dessa situação é usar uma infraestrutura certificada que suporte MAC.

Então, o que temos no set:

Agora, vamos ver como você pode usar essa infraestrutura ao desenvolver um aplicativo para preservar as funções de controle de acesso no nível da infraestrutura.

Para que o aplicativo aproveite o mecanismo de etiqueta obrigatório do sistema operacional, as seguintes condições devem ser atendidas:

• Os usuários do aplicativo devem estar registrados no armazenamento de usuários do sistema operacional. No mínimo, deve haver algum identificador que permita mapear exclusivamente o usuário do aplicativo para o usuário do sistema operacional (geralmente este é o login).
• Os usuários de aplicativos no nível do mecanismo MAC do sistema operacional devem ser configurados com permissões de credenciais para credenciais específicas (intervalos de credenciais).

Do ponto de vista do aplicativo de desktop, o cenário do usuário é o seguinte:

1. O usuário entra no SO sob seu ultra-som pessoal no modo de etiqueta de que precisa. Inicia o aplicativo. O processo do aplicativo herda o rótulo da credencial.
2. O aplicativo interage com o banco de dados no PostgreSQL, exibindo, por exemplo, apenas registros de tabelas do banco de dados com o rótulo de credencial atual.

Do ponto de vista do aplicativo de servidor que fornece serviços da Web, o cenário do usuário é conceitualmente próximo, embora pareça um pouco mais complicado:

1. O usuário entra no SO sob seu ultra-som pessoal no modo de etiqueta de que precisa. Ele inicia um navegador com suporte a MAC, em nosso exemplo, o Mozilla Firefox (um navegador "normal" não funciona para esses fins). O processo do navegador herda a credencial.
2. O usuário solicita o endereço do recurso do aplicativo com suporte a credenciais. O navegador forma uma solicitação adicionando uma marca de credencial.
3. A solicitação é processada por um servidor da web com suporte para credenciais, em nosso exemplo, Apache Http Server. O servidor da Web (cujo processo opera no modo de credencial mínima) lê o rótulo da credencial da solicitação, localiza o aplicativo manipulador e inicia seu processo com a etiqueta da credencial passada.
4. O aplicativo interage com o banco de dados PostgreSQL, retransmitindo o rótulo da credencial nas consultas.

A presença do MAC no sistema operacional impõe restrições bastante sérias na arquitetura do aplicativo. O fato de que em um sistema operacional sem um modelo de controle de acesso credencial parece trivial em um sistema operacional com um MAC pode trazer muitas surpresas para toda a equipe de desenvolvimento. Especialmente para o gerente de projetos. Portanto, a arquitetura de um aplicativo habilitado para MAC deve ser criada antes do início do desenvolvimento. O gerente de projeto do MAC deve insistir para que o projeto seja feito pela equipe de arquitetura antes de qualquer movimento em direção à implementação.

Obviamente, para o desenvolvimento de aplicativos simples (utilitários ou aplicativos, devido à sua especificidade neutra em relação ao MAC), muitas dicas simplesmente não são úteis. Se o aplicativo for algo mais complexo que um aplicativo local de usuário único que lê um arquivo e grava o resultado de seu trabalho em um arquivo, é aconselhável entender claramente as "armadilhas".

Reunimos receitas para projetar um aplicativo com suporte a MAC, formulado com base em nossa própria experiência. Atrás deles, há noites sem dormir, um fluxo contínuo de tickets de teste, milhares de horas depurando um aplicativo que, por todo o senso comum, deve funcionar corretamente, mas por algum motivo não funciona assim. As receitas são descritas da forma mais simples e neutra às tecnologias e ferramentas e, se possível, equipadas com esquemas para melhorar a percepção. Vamos lá!

Como evitar o MAC quando ele não pode mais ser evitado

Ao projetar um aplicativo com MAC, você pode usar uma solução arquitetural muito simples, que no final poupa muitos nervos e tempo. Um parâmetro deve ser adicionado à configuração do aplicativo que informa ao aplicativo se o modelo de controle de acesso à credencial para esta instalação está ativado ou não. Em todos os locais do aplicativo em que a interação com a infraestrutura MAC ocorre, ou a função comercial do aplicativo requer verificação de etiqueta, você deve primeiro verificar o valor desse parâmetro. Se o MAC estiver desativado de acordo com ele, o aplicativo ignorará todas as regras de lógica de negócios projetadas para testar funções compatíveis com MAC.

Em termos de custos de mão-de-obra, você terá que gastar tempo adicional implementando cada função do aplicativo com suporte a MAC. Você precisará depurar e testar a mesma funcionalidade no modo sem um rótulo de credencial, para aumentar o custo do teste.

Devido a esta solução, é possível fornecer ao aplicativo (e toda a equipe de desenvolvimento), que é forçado a funcionar no ambiente MAC, as seguintes vantagens:

• Aplicativo de plataforma cruzada (limitado apenas pelos recursos das linguagens de programação) e sua independência do tempo de execução.
• A capacidade de usar ferramentas modernas de virtualização (por exemplo, Docker) para automação.
• Facilidade de teste e recursos de depuração que não estão diretamente relacionados ao MAC.

Recomendações :

Adicione a opção para ativar / desativar o suporte para credenciais no aplicativo.

Em todos os locais que requerem interação com o MAC, verifique primeiro o valor do parâmetro.

Ao depurar e testar, é necessário depurar (no lado da equipe de desenvolvimento) e testar (no lado da equipe de teste) ambos os modos do aplicativo.

Dividir e conquistar

Outra etapa importante do projeto que deve ser concluída antes do início do desenvolvimento é a separação dos módulos nos quais o suporte MAC é necessário dos módulos nos quais esse mecanismo de controle de acesso não é necessário. O uso de um modelo de controle de acesso credencial quase sempre complica a lógica comercial de um aplicativo.

Essa é a mesma infra-estrutura, abstraindo da qual é muito difícil e às vezes impossível. Portanto, o aplicativo deve ser dividido em módulos e, para cada módulo, analisar a necessidade de suporte ao MAC. Talvez seja no seu caso que seja suficiente oferecer suporte ao MAC em apenas um módulo, e não faz sentido, por causa desse módulo, complicar todo o aplicativo?
Se estivermos considerando um determinado módulo abstrato (ou o aplicativo inteiro, se a divisão do aplicativo em módulos não for necessária), os seguintes paradigmas são possíveis:

• O rótulo mínimo. O módulo processa dados no modo de etiqueta obrigatória mínima (a etiqueta mínima na qual os processos do SO operam - por exemplo, 0 etiqueta obrigatória) ou sem uma etiqueta obrigatória.
• Um rótulo. O módulo trabalha com os dados de apenas uma etiqueta obrigatória acima da etiqueta obrigatória mínima (qualquer etiqueta diferente daquela na qual os processos do SO operam).
• Várias etiquetas. O módulo trabalha com os dados de vários rótulos obrigatórios de uma só vez (o rótulo no qual os processos do SO operam e outros rótulos que não sejam o rótulo do processo do SO).

Os módulos de aplicativos com diferentes paradigmas de processamento de credenciais não devem saber muito um do outro. Caso contrário, está repleto de problemas grandes e imprevisíveis relacionados a conflitos de acesso a vários objetos, etc. A idéia de conectividade mínima para módulos é óbvia. No caso de trabalhar com o MAC, você deve estar especialmente vigilante e monitorar todas as "conexões" dos módulos.
A seguir, consideramos com mais detalhes os recursos de design com três paradigmas para o processamento de credenciais. Para fazer isso, esboçamos a classificação de simples a complexas. Esta classificação é puramente prática e aplicada. Ele procede de diferenças intuitivamente tangíveis no desenvolvimento de vários módulos e, na prática, demonstrou sua eficácia.

Classificação de módulos por modos de processamento MAC

“BRING IT ON”: operação do módulo no modo credencial mínimo

Motivação para implementar este mecanismo no módulo:

• O módulo processa informações que, em princípio, não podem ser processadas no sistema com outras credenciais e não exigem privilégios especiais de leitura / gravação.
• O módulo está intimamente conectado à infraestrutura do sistema operacional, o que limita seu funcionamento no modo de etiqueta obrigatório, que é diferente do mínimo.

O módulo que opera neste modo deve verificar a credencial do processo. Se o rótulo do processo em que este módulo está executando for diferente do mínimo (por exemplo, ele não é igual ao rótulo obrigatório 0), todas as operações (exceto a visualização) deverão ser proibidas no nível da lógica de negócios do aplicativo. Ou seja, podemos simplesmente não permitir que o usuário use este módulo se ele veio até nós em uma sessão com um rótulo de credencial diferente de zero.

Exemplos de casos práticos para os quais o uso do modo mínimo de etiqueta obrigatória é adequado:

• Gerenciar contas de usuário na loja de aplicativos. Por exemplo, se o aplicativo mantiver seu próprio registro de ultrassom em um arquivo ou banco de dados. Todos os dados relacionados à segurança e controle de acesso do aplicativo devem ser armazenados no modo de credencial mínimo; caso contrário, o modelo de segurança do aplicativo simplesmente "desmorona" quando o aplicativo está sendo executado no modo de marca de credencial. Por esse motivo, todos os aplicativos do sistema são executados estritamente com a credencial mínima.
• Gerenciamento de direitos de acesso. Por exemplo, se o aplicativo implementar seu próprio modelo de controle de acesso no nível da lógica de negócios.
• Gerencie as configurações do aplicativo que devem estar disponíveis em todas as credenciais.
• Gerenciamento de contas no SO. Se o aplicativo precisar gerenciar quaisquer atributos do KM no sistema operacional, todas as operações deverão ser executadas estritamente sob a marca mínima de credencial.

“ME PERGUNTA”: operação do módulo no modo de credencial única

Esse caso é um pouco mais complicado, mas de várias maneiras semelhante ao caso com uma marca de credencial mínima. Do ponto de vista do usuário, o trabalho com o aplicativo não muda muito: todas as mesmas listas familiares de registros, cartões e operações "View", "Edit" e "Save". A única diferença é que, nesse modo, o usuário vê apenas os registros que correspondem à marca de credencial de sua sessão atual.

Uma opção limitada também pode ser desenvolvida: o módulo captura o valor do parâmetro "rótulo de credencial padrão". Nesse caso, a operação do módulo é possível apenas com o rótulo de credencial especificado, mas essa opção é mais fácil de implementar.

Este caso pode ser útil nos seguintes casos:

• Houve um erro na arquitetura ao projetar o módulo (os recursos de processamento de registros no MAC não foram estabelecidos) e não há tempo ou recursos para reescrever tudo.
• O suporte ao modelo de controle de acesso credencial é introduzido em um aplicativo já em funcionamento e, de acordo com os requisitos, é necessário garantir o trabalho com uma etiqueta acima do mínimo no sistema operacional. Sim, este é o caso quando a cabeça chega até você e informa com prazer que vencemos o concurso e implementamos nossa decisão em "nome do departamento secreto" !
• Não há razão para implementar o suporte total ao processamento simultâneo de registros de várias credenciais. Não há necessidade de processamento simultâneo de registros de várias credenciais ao mesmo tempo.
• O aplicativo opera no modo de usuário único.

Do ponto de vista da implementação, este caso não é muito simples, pois precisamos:

• Selecione apenas os registros que correspondem à etiqueta obrigatória atual, pois, de acordo com o modelo de Bell-Lapadula, o usuário verá registros da etiqueta obrigatória atual e de todas as etiquetas obrigatórias localizadas mais abaixo na hierarquia.
• Verifique a marca da credencial antes de executar qualquer operação para modificar o registro. Se você tentar fazer uma alteração em uma entrada com um rótulo de credencial diferente de um rótulo de credencial para uma sessão, a operação deverá ser interrompida.

Ao executar operações no módulo, é recomendável verificar o rótulo da credencial do processo atual do aplicativo com o rótulo da credencial padrão. Se o rótulo da credencial do módulo não corresponder ao rótulo da credencial da sessão, o usuário não deverá ter permissão para executar a operação.

Exemplos de casos práticos para os quais o uso do modo de rótulo de credencial único é adequado:

• . , ( , ..). , . .
• . , , ( ) . «» , « », «» .

«NIGHTMARE!»:

Este modo de operação é útil apenas se em uma sessão com o módulo precisarmos exibir informações sobre todas as credenciais localizadas abaixo das credenciais da sessão atual na hierarquia.

Ao projetar, é necessário descrever os requisitos funcionais do módulo e, nos detalhes de cada requisito funcional, indicar a lista de interações em termos do modelo obrigatório (as opções possíveis são discutidas abaixo na seção “Interação entre o aplicativo e o ambiente”). Isso destacará alguns conceitos gerais de interação com a infraestrutura em relação às tags obrigatórias. Além disso, essas informações serão extremamente úteis para avaliar a complexidade do desenvolvimento e outros testes.

Em termos de implementação da interface do usuário, os seguintes padrões são comumente usados:

• (, ) ( ). , .
• / / , .
• / ( ).

Um conjunto adicional de processos de negócios depende da complexidade da lógica de negócios do módulo e das especificidades do processamento de dados. Por exemplo, você pode filtrar a coleção de registros por rótulo de credencial. Você pode exibir a etiqueta de registro da credencial na interface.

O escopo das combinações é enorme, assim como o espaço para que os erros apareçam. Portanto, não é recomendável processar registros com uma marca de credencial diferente dentro do mesmo caso de usuário na presença de qualquer lógica comercial. Quaisquer operações com a coleção de registros devem ser realizadas com uma indicação explícita das credenciais comuns a toda a coleção. Processou a terceira marca, depois a segunda, etc.

Para implementar este modo, é necessário estabelecer as seguintes funções:

• A função obtém o rótulo da credencial do processo atual do aplicativo (sessão do usuário).
• A função de obter uma marca de credencial para um registro (se for uma questão de trabalhar com um registro no banco de dados) ou um arquivo (se for uma questão de processar arquivos).
• A função de receber o rótulo de credencial dos registros / arquivos do banco de dados na coleção.

Exemplos de casos práticos para os quais o modo de várias credenciais é adequado:

1. Relatórios Para implementar esse caso, precisamos acumular o máximo de informações sobre o sistema, disponíveis para uma sessão com o rótulo obrigatório atual.
2. A revista. Nesse caso, uma interface é desenvolvida para exibir todas as operações disponíveis para visualização com a capacidade de filtrar, inclusive por rótulo de credencial.

Interação Ambiental

Um aplicativo em um ambiente MAC interage com uma lista específica de componentes ao seu redor. Esquematicamente de acordo com os recursos da interação, eles podem ser classificados da seguinte forma:

• Sistema operacional:
  
  • Parâmetros do modelo de credencial:
    
    • A hierarquia de rótulos obrigatórios OS;
    • Permissões obrigatórias (intervalos de etiquetas que um usuário específico pode usar) Usuários do SO.
  • Armazenamento de credenciais do usuário
  • Autenticação no sistema operacional (incluindo levar em conta credenciais);
  • Outros mecanismos de controle de acesso (POSIX ACL, UNIX, etc.);
  • Trabalhar com FS;
  • Gerenciamento de processos;
  • Trabalhe com uma rede;
• Software de terceiros sem suporte a MAC;
• Software de terceiros com suporte a MAC:
  
  • DBMS (por exemplo, PostgreSQL):
    
    • Objetos de banco de dados (células, linhas, colunas, esquemas, tabelas, bancos de dados, clusters, sequências, funções, etc.).
• Usuário

Vamos considerar as nuances da interação com cada um dos componentes separadamente.

Interação de um aplicativo compatível com MAC com o sistema operacional

O MAC está muito "feliz" com suas dificuldades em definir regras de acesso no sistema de arquivos. Por exemplo, a maior parte dos erros nos aplicativos MAC está relacionada ao fato de o aplicativo não ver o arquivo no modo de marca de credencial atual, mas o arquivo existe em outro modo de marca de credencial (um nível acima).

O que esperamos do sistema operacional em termos de MAC?

Se nosso aplicativo funcionar no modo multiusuário, provavelmente precisará solicitar informações sobre contas de usuário cujos dados processam. Isso é necessário para dar suporte ao controle de acesso do usuário. Portanto, o aplicativo precisará solicitar informações do sistema operacional sobre credenciais do usuário. Se o KM do usuário no SO for controlado por nosso aplicativo, precisamos não apenas ler as informações sobre o KM, mas também gerenciar os atributos do KM.

Os fluxos mais prováveis ​​de interações entre o SO e o aplicativo são mostrados no diagrama:

Interação de um aplicativo compatível com MAC com software de terceiros sem suporte para MAC

A maioria dos aplicativos que podem ser usados ​​em um sistema operacional com um MAC não sabe como processar um MAC.

Portanto, ao organizar essa interação, é necessário emular um rótulo de credencial ao transferir dados ou uma solicitação para o processo de um aplicativo. Isso é realizado pela "estratificação" do fluxo de dados em canais separados, cada um dos quais é logicamente projetado para dados com um determinado rótulo obrigatório. É estritamente proibido misturar esses dados; eles devem passar por filas, canais e quase por fios separados de pares trançados para interfaces de rede. A validade da implementação "lógica" da separação de dados pelo MAC também é uma questão controversa; portanto, na maioria das vezes reside na consciência do cliente e do desenvolvedor do aplicativo.

A capacidade de usar um aplicativo sem MAC por um aplicativo em execução no modo MAC depende do método de interação selecionado, de suas especificidades e dos recursos de implementação do processamento de dados recebidos no aplicativo.

Interação de um aplicativo compatível com MAC com software de terceiros com suporte a MAC

No caso de interação com software com suporte a MAC, nosso aplicativo deve claramente ler o rótulo do processo que está fazendo a solicitação e executar a operação de acordo com o modelo de controle de acesso obrigatório. Um aplicativo que interage com esse software é necessário apenas para atender solicitações a um aplicativo / processo de terceiros a partir de um processo com a marca de credencial correta.

Um exemplo de um aplicativo popular com suporte completo para rótulos obrigatórios é o PostgresSQL. Em certas variantes da entrega desse DBMS, o suporte total ao MAC é implementado para alguns sistemas operacionais com mecanismos MAC, por exemplo:

• Astra Linux: PostgreSQL, que vem com a versão do kit de distribuição do SE.
• SELinux: extensão sepgsql.

O PostgreSQL permite separar dados por rótulos de credenciais (ainda há suporte para categorias de credenciais, mas estamos interessados ​​em rótulos) nos seguintes níveis:

• No nível do cluster.
• No nível do banco de dados do cluster.
• No nível do esquema do banco de dados do cluster.
• No nível da tabela do esquema do banco de dados do cluster.
• No nível da coluna da tabela de esquema do banco de dados do cluster.
• No nível do registro da tabela de esquema do banco de dados do cluster.

Como resultado, na implementação do MAC, obtemos uma "boneca de aninhamento": cada nível de "pai" impõe suas próprias restrições em todos os níveis de "filho". Portanto, ao implementar a interação com cada aplicativo semelhante com suporte total ao MAC, é necessário levar em consideração suas especificidades de trabalho. Não há receitas universais.

Interoperabilidade do usuário de um aplicativo compatível com MAC

Não importa o quão estranho esse aspecto da interação possa parecer em comparação com os considerados anteriormente, é impossível não insistir nele. Afinal, é para o usuário que os aplicativos com suporte a MAC costumam ser criados, certo?

Um aplicativo com suporte a MAC praticamente não difere daquele sem um MAC em termos de interface do usuário em todos os modos, exceto no modo de trabalho simultâneo com várias credenciais.

No exemplo de aplicativos da web comuns hoje em dia, os seguintes casos são mais frequentemente encontrados:

Conclusões

Examinamos vários aspectos do desenvolvimento de um aplicativo com suporte a MAC. É claro que é difícil prever todos os casos. A maioria dos recursos do modelo de credenciais depende da implementação disponível para uso no sistema operacional selecionado.

O suporte ao aplicativo MAC não é um "recurso" adicional do aplicativo. Esta é uma solução arquitetônica séria que requer planejamento e design. A maior “dor” para o designer de um aplicativo compatível com MAC:

• interação com a infraestrutura do sistema operacional (sistema de arquivos, interações de rede, processos iniciados com o rótulo de credencial desejado, caso a aplicação seja executada no servidor);
• interação com software aplicativo com suporte a MAC incorporado (por exemplo, DBMS);
• interação do usuário com relação ao processamento correto de operações compatíveis com MAC.

Por enquanto é tudo! Adições, experiência pessoal e comentários sobre o artigo são bem-vindos!