Skip to main content
ONTAP Technical Reports
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Abordagens para controle de acesso baseado em atributos (ABAC) no ONTAP

Colaboradores netapp-dbagwell
PDFs

O ONTAP fornece várias abordagens que você pode usar para obter controle de acesso baseado em atributos de arquivo (ABAC), incluindo rótulos de segurança NFS v4,2 e atributos estendidos (xattrs) usando NFS.

Etiquetas de segurança NFS v4,2

A partir do ONTAP 9,9.1, o recurso NFS v4,2 chamado rotulado NFS é suportado.

Os rótulos de segurança NFS v4,2 são uma maneira de gerenciar o acesso granular a arquivos e pastas usando rótulos SELinux e Controle de Acesso obrigatório (MAC). Esses rótulos MAC são armazenados com arquivos e pastas e funcionam em conjunto com permissões UNIX e ACLs NFS v4.x.

O suporte para rótulos de segurança NFS v4,2 significa que a ONTAP agora reconhece e compreende as configurações de rótulo SELinux do cliente NFS. Os rótulos de segurança NFS v4,2 são cobertos no RFC-7204.

Os casos de uso de etiquetas de segurança NFS v4,2 incluem o seguinte:

  • MAC rotulagem de imagens de máquina virtual (VM)

  • Classificação de segurança de dados para o setor público (segredo, segredo principal e outras classificações)

  • Conformidade de segurança

  • Linux sem disco

Habilite rótulos de segurança NFS v4,2

Você pode ativar ou desativar rótulos de segurança NFS v4,2 com o seguinte comando (privilégio avançado necessário):

vserver nfs modify -vserver <svm_name> -v4.2-seclabel <disabled|enabled>

Saiba mais sobre vserver nfs modify o "Referência do comando ONTAP"na .

Modos de aplicação para rótulos de segurança NFS v4,2

A partir do ONTAP 9,9.1, o ONTAP suporta os seguintes modos de aplicação:

  • Modo de servidor limitado: O ONTAP não pode impor as etiquetas, mas pode armazená-las e transmiti-las.

    Observação A capacidade de alterar etiquetas MAC depende do cliente para impor.

  • Modo convidado: Se o cliente não estiver identificado como NFS-Aware (v4,1 ou inferior), os rótulos MAC não serão transmitidos.

    Observação Atualmente, o ONTAP não suporta o modo completo (armazenamento e aplicação de etiquetas MAC).

Exemplos de rótulos de segurança NFS v4,2

A configuração de exemplo a seguir demonstra conceitos usando o Red Hat Enterprise Linux versão 9,3 (Plow).

O usuário jrsmith, criado com base nas credenciais de John R. Smith, tem o seguinte Privileges de conta:

  • Nome de utilizador jrsmith

  • Privileges uid=1112(jrsmith) gid=1112(jrsmith) groups=1112(jrsmith) context=user_u:user_r:user_t:s0

Há duas funções: A conta de administrador que é um usuário privilegiado e usuário jrsmith, conforme descrito na seguinte tabela MLS Privileges:

Usuários Função Tipo Níveis

admins

sysadm_r

sysadm_t

t:s0

jrsmith

user_r

user_t

t:s1 - t:s4

Neste ambiente de exemplo, o usuário jrsmith tem acesso a arquivos nos níveis s0 s3 de . Podemos aprimorar as classificações de segurança existentes, conforme descrito abaixo, para garantir que os administradores não tenham acesso a dados específicos do usuário.

  • s0: dados de usuário do administrador de privilégios

  • s0: dados não classificados

  • s1: confidencial

  • s2: dados secretos

  • s3: dados secretos principais

Exemplo de etiquetas de segurança NFS v4,2 com MCS

Além do MLS (Multi-Level Security), outro recurso chamado MCS (Multi-Category Security) permite definir categorias como projetos.

Etiqueta de segurança NFS Valor

entitySecurityMark

t:s01 = UNCLASSIFIED

Atributos estendidos (xattrs)

A partir do ONTAP 9.12.1, o ONTAP suporta xattrs. Os xattrs permitem que os metadados sejam associados a arquivos e diretórios além do que é fornecido pelo sistema, como listas de controle de acesso (ACLs) ou atributos definidos pelo usuário.

Para implementar o xattrs, você pode usar setfattr e getfattr utilitários de linha de comando no Linux. Essas ferramentas fornecem uma maneira poderosa de gerenciar metadados adicionais para arquivos e diretórios. Eles devem ser usados com cuidado, pois o uso inadequado pode levar a comportamentos inesperados ou problemas de segurança. Consulte sempre as setfattr páginas de manual e getfattr ou outra documentação fiável para obter instruções de utilização detalhadas.

Quando o xattrs está habilitado em um sistema de arquivos ONTAP, os usuários podem definir, modificar e recuperar atributos arbitrários em arquivos. Esses atributos podem ser usados para armazenar informações adicionais sobre o arquivo que não é capturado pelo conjunto padrão de atributos de arquivo, como informações de controle de acesso.

Existem vários requisitos e limites para o uso de xattrs no ONTAP:

  • Red Hat Enterprise Linux 8,4 ou posterior

  • Ubuntu 22,04 ou posterior

  • Cada arquivo pode ter até 128 xattrs

  • As chaves xattr estão limitadas a 255 bytes

  • O tamanho combinado da chave ou do valor é de 1.729 bytes por xattr

  • Diretórios e arquivos podem ter xattrs

  • Para definir e recuperar xattrs w, ou bits de modo de gravação devem estar ativados para o usuário e grupo

Os Xattrs são utilizados dentro do namespace do usuário e não carregam nenhum significado intrínseco para o próprio ONTAP. Em vez disso, suas aplicações práticas são determinadas e gerenciadas exclusivamente pelo aplicativo do lado do cliente que interage com o sistema de arquivos.

Exemplos de casos de uso do xattr:

  • Gravando o nome do aplicativo responsável pela criação de um arquivo

  • Manter uma referência à mensagem de e-mail a partir da qual um arquivo foi obtido

  • Estabelecendo uma estrutura de categorização para organizar objetos de arquivo

  • Rotular arquivos com o URL de sua fonte de download original

Comandos para gerenciar xattrs

  • setfattr define um atributo estendido de um arquivo ou diretório:

    setfattr -n <attribute_name> -v <attribute_value> <file or directory name>

    Exemplo de comando:

    setfattr -n user.comment -v test example.txt

  • getfattr recupera o valor de um atributo estendido específico ou lista todos os atributos estendidos de um arquivo ou diretório:

    Atributo específico: getfattr -n <attribute_name> <file or directory name>

    Todos os atributos: getfattr <file or directory name>

    Exemplo de comando:

    getfattr -n user.comment example.txt

Exemplos de pares de valores de chave xattr

A tabela a seguir mostra dois exemplos de pares de valores de chave xattr:

xattr Valor

user.digitalIdentifier

CN=John Smith jrsmith, OU=Finance, OU=U.S.ACME, O=US, C=US

user.countryOfAffiliations

USA

Permissões de usuário com ACE para xattrs

Uma entrada de controle de acesso (ACE) é um componente dentro de uma ACL que define os direitos de acesso ou permissões concedidas a um usuário individual ou a um grupo de usuários para um recurso específico, como um arquivo ou diretório. Cada ACE especifica o tipo de acesso permitido ou negado e está associado a um responsável de segurança específico (identidade de usuário ou grupo).

Entrada de controle de acesso (ACE) necessária para xattrs

  • Recuperar xattr: As permissões necessárias para um usuário ler os atributos estendidos de um arquivo ou diretório. O "R" significa que a permissão de leitura é necessária.

  • Definir xattrs: As permissões necessárias para modificar ou definir os atributos estendidos. "A", "W" e "T" representam diferentes exemplos de permissões, como anexar, escrever e uma permissão específica relacionada ao xattrs.

  • Arquivos: Os usuários precisam anexar, escrever e potencialmente uma permissão especial relacionada ao xattrs para definir atributos estendidos.

  • Diretórios: Uma permissão específica "T" é necessária para definir atributos estendidos.

Tipo de ficheiro Recuperar xattr Definir xattrs

Ficheiro

R

A, W, T

Diretório

R

T

Integração com software de controle de acesso e identidade ABAC

Para aproveitar totalmente os recursos do ABAC, o ONTAP pode se integrar com um software de gerenciamento de identidade e acesso orientado ao ABAC.

Em um sistema ABAC, o ponto de aplicação da Política (PEP) e o ponto de Decisão da Política (PDP) desempenham papéis cruciais. O PEP é responsável pela aplicação de políticas de controle de acesso, enquanto o PDP toma a decisão de conceder ou negar acesso com base nas políticas.

Em um ambiente prático, uma organização empregaria uma mistura de rótulos de segurança NFS e xattrs. Estes são usados para representar uma variedade de metadados, incluindo classificação, segurança, aplicação e conteúdo, que são todos fundamentais na tomada de decisões ABAC.xatrs, por exemplo, pode ser usado para armazenar os atributos de recursos que o PDP usa para seu processo de tomada de decisão. Um atributo pode ser definido para representar o nível de classificação de um arquivo (por exemplo, "não classificado", "confidencial", "segredo" ou "segredo superior"). O PDP poderia então utilizar este atributo para impor uma política que restringe os utilizadores a aceder apenas a ficheiros que tenham um nível de classificação igual ou inferior ao nível de autorização.

Observação Este conteúdo pressupõe que os serviços de identidade, autenticação e acesso do cliente incluem, no mínimo, um PEP e um PDP que atuam como intermediários para o acesso ao sistema de arquivos.
Exemplo de fluxo de processo para ABAC

  1. O usuário apresenta credenciais (por exemplo, PKI, OAuth, SAML) para acesso ao sistema ao PEP e obtém resultados do PDP.

    A função do PEP é intercetar a solicitação de acesso do usuário e encaminhá-la para o PDP.

  2. Em seguida, o PDP avalia essa solicitação em relação às políticas estabelecidas da ABAC.

    Essas políticas consideram vários atributos relacionados ao usuário, ao recurso em questão e ao ambiente circundante. Com base nessas políticas, o PDP toma uma decisão de acesso para permitir ou negar e, em seguida, comunica essa decisão de volta ao PEP.

    PDP fornece política para PEP para fazer cumprir. O PEP então impõe essa decisão, concedendo ou negando o pedido de acesso do usuário conforme decisão do PDP.

  3. Após uma solicitação bem-sucedida, o usuário solicita um arquivo armazenado no ONTAP (AFF, AFF-C, por exemplo).

  4. Se a solicitação for bem-sucedida, o PEP obtém tags de controle de acesso de grãos finos do documento.

  5. PEP solicita política para o utilizador com base nos certificados desse utilizador.

  6. O PEP toma uma decisão com base na política e nas tags se o usuário tiver acesso ao arquivo e permitir que o usuário recupere o arquivo.

Observação O acesso real pode ser feito usando tokens.

Arquitetura de acesso ABAC

Clonagem de ONTAP e SnapMirror

As tecnologias de clonagem e SnapMirror da ONTAP foram projetadas para fornecer recursos de replicação e clonagem de dados eficientes e confiáveis, garantindo que todos os aspetos dos dados de arquivos, incluindo xatrs, sejam preservados e transferidos juntamente com o arquivo. Os xatrs são críticos, pois armazenam metadados adicionais associados a um arquivo, como rótulos de segurança, informações de controle de acesso e dados definidos pelo usuário, essenciais para manter o contexto e integridade do arquivo.

Quando um volume é clonado usando a tecnologia FlexClone da ONTAP, uma réplica gravável exata do volume é criada. Esse processo de clonagem é instantâneo e eficiente em espaço, e inclui todos os dados e metadados de arquivos, garantindo que os xatrs sejam totalmente replicados. Da mesma forma, o SnapMirror garante que os dados sejam espelhados para um sistema secundário com fidelidade total. Isso inclui xattrs, que são cruciais para aplicativos que dependem desses metadados para funcionar corretamente.

Ao incluir xatrs nas operações de clonagem e replicação, o NetApp ONTAP garante que todo o conjunto de dados, com todas as suas características, esteja disponível e consistente em sistemas de storage primário e secundário. Essa abordagem abrangente ao gerenciamento de dados é vital para organizações que exigem proteção de dados consistente, recuperação rápida e adesão a padrões regulatórios e de conformidade. Ele também simplifica o gerenciamento de dados em diferentes ambientes, seja no local ou na nuvem, fornecendo aos usuários a confiança de que seus dados estão completos e inalterados durante esses processos.

Observação As etiquetas de segurança NFS v4,2 têm as ressalvas definidas no 2.

Auditoria de alterações em rótulos

A auditoria de alterações em rótulos de segurança xattrs ou NFS é um aspeto crítico do gerenciamento e da segurança do sistema de arquivos. As ferramentas padrão de auditoria do sistema de arquivos permitem o monitoramento e o Registro de todas as alterações em um sistema de arquivos, incluindo modificações em xattrs e rótulos de segurança.

Em ambientes Linux, o auditd daemon é comumente usado para estabelecer auditoria para eventos de sistema de arquivos. Ele permite que os administradores configurem regras para observar chamadas específicas do sistema relacionadas a alterações xattr, como setxattr, lsetxattr e fsetxattr para definir atributos e, lremovexattr e fremovexattr para removexattr remover atributos.

O ONTAP FPolicy amplia esses recursos fornecendo uma estrutura robusta para monitoramento e controle em tempo real de operações de arquivos. O FPolicy pode ser configurado para oferecer suporte a vários eventos xattr, oferecendo controle granular sobre as operações de arquivos e a capacidade de aplicar políticas abrangentes de gerenciamento de dados.

Para usuários que utilizam xattrs, especialmente em ambientes NFS v3 e NFS v4, apenas determinadas combinações de operações de arquivos e filtros são suportadas para monitoramento. A lista de combinações de filtro e operação de arquivos compatíveis para monitoramento FPolicy de eventos de acesso a arquivos NFS v3 e NFS v4 é detalhada abaixo:

Operações de arquivos compatíveis Filtros suportados

setattr

offline-bit, setattr_with_owner_change, setattr_with_group_change, setattr_with_mode_change, setattr_with_modify_time_change, setattr_with_access_time_change, setattr_with_size_change, exclude_directory
Exemplo de um snippet de log auditd para uma operação setattr:
type=SYSCALL msg=audit(1713451401.168:106964): arch=c000003e syscall=188
success=yes exit=0 a0=7fac252f0590 a1=7fac251d4750 a2=7fac252e50a0 a3=25
items=1 ppid=247417 pid=247563 auid=1112 uid=1112 gid=1112 euid=1112
suid=1112 fsuid=1112 egid=1112 sgid=1112 fsgid=1112 tty=pts0 ses=141
comm="python3" exe="/usr/bin/python3.9"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
key="*set-xattr*"ARCH=x86_64 SYSCALL=**setxattr** AUID="jrsmith"
UID="jrsmith" GID="jrsmith" EUID="jrsmith" SUID="jrsmith"
FSUID="jrsmith" EGID="jrsmith" SGID="jrsmith" FSGID="jrsmith"

Habilitar "Política de ONTAP" para usuários que trabalham com xattrs fornece uma camada de visibilidade e controle que é essencial para manter a integridade e a segurança do sistema de arquivos. Ao aproveitar os recursos avançados de monitoramento da FPolicy, as organizações podem garantir que todas as alterações aos xattrs sejam rastreadas, auditadas e alinhadas com seus padrões de segurança e conformidade. Essa abordagem proativa para o gerenciamento do sistema de arquivos é por isso que habilitar o ONTAP FPolicy é altamente recomendado para qualquer organização que queira aprimorar suas estratégias de governança e proteção de dados.

Exemplos de controle do acesso aos dados

A seguinte entrada de exemplo para dados armazenados no cert PKI de John R. Smith mostra como a abordagem do NetApp pode ser aplicada a um arquivo e fornecer controle de acesso refinado.

Observação Esses exemplos são para fins ilustrativos, e é responsabilidade do cliente determinar os metadados associados a etiquetas de segurança NFS v4,2 e xattrs. Detalhes sobre a atualização e retenção de rótulos são omitidos para simplificar.

Exemplo de valores de cert PKI

Chave Valor

EntitySecurityMark

t:S01 NÃO CLASSIFICADO

Informações

 
{
  "commonName": {
    "value": "Smith John R jrsmith"
  },
  "emailAddresses": [
    {
      "value": "jrsmith@dod.mil"
    }
  ],
  "employeeId": {
    "value": "00000387835"
  },
  "firstName": {
    "value": "John"
  },
  "lastName": {
    "value": "Smith"
  },
  "telephoneNumber": {
    "value": "938/260-9537"
  },
  "uid": {
    "value": "jrsmith"
  }
}

especificação

"DoD"

uuid

b4111349-7875-4115-ad30-0928565f2e15

AdminOrganization

 
{
   "value": "DoD"
}

briefings

 
[
  {
    "value": "ABC1000"
  },
  {
    "value": "DEF1001"
  },
  {
    "value": "EFG2000"
  }
]

CitizensaStatus

 
{
  "value": "US"
}

folgas

 
[
  {
    "value": "TS"
  },
  {
    "value": "S"
  },
  {
    "value": "C"
  },
  {
    "value": "U"
  }
]

CountryOfAffiliations

 
[
  {
    "value": "USA"
  }
]

DigitalIdentifier

 
{
  "classification": "UNCLASSIFIED",
  "value": "cn=smith john r jrsmith, ou=dod, o=u.s. government, c=us"
}

It is always

 
{
   "value": "DoD"
}

DutyOrganization

 
{
   "value": "DoD"
}

Tipo de entidade

 
{
   "value": "GOV"
}

FineAccessControls

 
[
   {
      "value": "SI"
   },
   {
      "value": "TK"
   },
   {
      "value": "NSYS"
   }
]

Esses direitos PKI mostram os detalhes de acesso de John R. Smith, incluindo acesso por tipo de dados e atribuição.

Em cenários em que os metadados IC-TDF são armazenados separadamente do arquivo, o NetApp defende uma camada adicional de controle de acesso refinado. Isso envolve o armazenamento de informações de controle de acesso tanto no nível de diretório quanto em associação com cada arquivo. Como exemplo, considere as seguintes tags vinculadas a um arquivo:

  • Rótulos de segurança NFS v4,2: Utilizados para tomar decisões de segurança

  • Xattrs: Fornecer informações complementares pertinentes ao arquivo e aos requisitos do programa organizacional

Os pares chave-valor a seguir são exemplos de metadados que podem ser armazenados como xattrs e oferecer informações detalhadas sobre o criador do arquivo e classificações de segurança associadas. Esses metadados podem ser aproveitados por aplicativos clientes para tomar decisões de acesso informado e organizar arquivos de acordo com os padrões e requisitos organizacionais.

  • Exemplo de pares de chave-valor xattr*

Chave Valor

user.uuid

"761d2e3c-e778-4ee4-997b-3bb9a6a1d3fa"

user.entitySecurityMark

"UNCLASSIFIED"

user.specification

"INFO"

user.Info

 
{
  "commonName": {
    "value": "Smith John R jrsmith"
  },
  "currentOrganization": {
    "value": "TUV33"
  },
  "displayName": {
    "value": "John Smith"
  },
  "emailAddresses": [
    "jrsmith@example.org"
  ],
  "employeeId": {
    "value": "00000405732"
  },
  "firstName": {
    "value": "John"
  },
  "lastName": {
    "value": "Smith"
  },
  "managers": [
    {
      "value": ""
    }
  ],
  "organizations": [
    {
      "value": "TUV33"
    },
    {
      "value": "WXY44"
    }
  ],
  "personalTitle": {
    "value": ""
  },
  "secureTelephoneNumber": {
    "value": "506-7718"
  },
  "telephoneNumber": {
    "value": "264/160-7187"
  },
  "title": {
    "value": "Software Engineer"
  },
  "uid": {
    "value": "jrsmith"
  }
}

user.geo_point

[-78.7941, 35.7956]
Informações relacionadas