Compartilhar via


Configuração avançada

O Protocolo de Segurança de Metadados (MSP) permite que os usuários definam opcionalmente listas de autorização personalizadas de Controle de Acesso Baseado em Função (RBAC) para pontos de extremidade de serviço de metadados para cada usuário e/ou processo. Essa lista de permissões é habilitada por um novo tipo de recurso na Galeria de Computação do Azure, a InVMAccessControlProfile.

Motivação

Tradicionalmente, os serviços de metadados tratam toda a VM (Máquina Virtual) como o limite de confiança e permitem que qualquer software em execução no convidado os acesse. Esse acesso é excessivamente permissivo, especialmente se sua carga de trabalho não for estritamente implementada com uma arquitetura nativa de nuvem moderna. O MSRC (Centro de Resposta de Segurança da Microsoft) descobriu que a maioria dos ataques de segurança poderia ter sido evitada limitando o acesso apenas ao software necessário.

O InVMAccessControlProfile permite que você defina um controle mais detalhado sobre os aplicativos/usuários que podem ter acesso aos pontos de extremidade. Ele permite que você escreva regras como:

  • A configuração de rede só pode ser acessada pelo Agente Convidado e pelo SQL Server
  • Tokens MSI (Identidade de Serviço Gerenciado) só podem ser acessados pela Extensão de Monitoramento

O novo tipo de recurso facilita o gerenciamento dessas configurações em escala. As regras apropriadas para sua VM dependem de qual software está em execução. Permite InVMAccessControlProfile que você defina sua configuração uma vez e vincule-a a todas as VMs aplicáveis.

Observação

É recomendável tratar esses controles como defesa detalhada na modelagem de ameaças. Esses controles podem aprimorar significativamente a segurança de uma carga de trabalho, mas são melhor usados como proteção extra em vez de como mecanismos de isolamento principais. Em cargas de trabalho multilocatários nativas de nuvem, especialmente se o código não confiável for executado, o isolamento com suporte de hardware/hipervisor, como oferecido pelas Instâncias de Contêiner do Azure , oferece uma proteção muito maior. As regras de autorização MSP complementam o isolamento respaldado por hardware.

Propriedades

Propriedade Tipo Detalhes
mode Enumeração: "Audit" \| "Enforce" \| "Disabled" Consulte a Configuração do MSP.
defaultAccess Enumeração: "Allow" \| "Deny" Controla se um ponto de extremidade é acessível ou restrito quando nenhum privilégio para esse recurso é especificado. Consulte Privilégios.
rules object A definição de RBAC a ser aplicada. Consulte regras de escrita.

Conceitos de Lista de Permitidos (RBAC) do MSP

A primeira etapa do controle de acesso é verificar a identidade do cliente. Normalmente, a verificação de identidade é feita usando algum tipo de credencial. O MSP foi projetado para evitar a introdução de alterações significativas nos clientes para maximizar a compatibilidade e facilitar a integração. Além disso, ter clientes atualizados com credenciais introduz outra camada de desafios de estabelecimento de confiança a serem resolvidos.

Em vez disso, o MSP dá suporte à definição de "identidades virtuais" em relação ao sistema operacional existente e aos metadados de processo. O kernel de uma VM mantém o controle de qual conta de usuário um processo pertence, além de outros metadados sobre sua invocação. O GPA é capaz de identificar qual processo fez a solicitação HTTP. Como resultado, o GPA pode acessar esses metadados para determinar a identidade de um chamador e tomar decisões de autorização.

Funções

As funções permitem agrupar vários privilégios em uma unidade nomeada e reutilizável. Eles são usados para melhorar a organização e a legibilidade.

Atribuições de função

Atribuições de função associam uma identidade a uma função. Ou seja, as solicitações provenientes de um processo que corresponde à identidade têm todos os privilégios associados a essa função.

Identidades

O MSP permite que o usuário defina um conjunto de condições a serem avaliadas em relação a um recipiente de propriedades de metadados de processo. Se todas as condições forem atendidas, o processo será considerado como pertencente a essa identidade e receberá privilégios.

O GPA dá suporte à escrita de regras de correspondência exatas em relação a esses metadados:

Metadados de processo Descrição
username O nome legível humano da conta em que o processo está sendo executado.
groupName O nome legível humano do grupo sob o qual o processo está em execução deve pertencer. Um usuário pode pertencer a vários grupos. As condições aqui são implementadas como um conjunto contém a operação.
processName O nome de exibição do processo. Observe que isso é uma questão de defesa em profundidade!
exePath O caminho completo do executável em execução. Para alguns programas, aparece o tempo de execução, e não o arquivo real que está sendo executado. Por exemplo, python.

A maneira ideal de configurar sua carga de trabalho seria executar cada aplicativo em uma conta de usuário dedicada com grupos com escopo exclusivo e, em seguida, escrever regras somente em relação a essas propriedades. A ID do usuário não pode ser falsificada e não há correspondência de padrões a ser seguida. No entanto, reconhecemos que isso não é prático em todas as cargas de trabalho, razão pela qual oferecemos as outras propriedades.

Se várias propriedades forem especificadas, a correspondência será executada como um AND lógico. Por exemplo, a definição de identidade:

{
    "name": "WebServer",
    "exePath": "/usr/sbin/apache2",
    "processName": "apache2",
    "groupName": "www-data"
}

Geraria a validação:

bool isWebServerIdentity = properties["exePath"] == "/usr/sbin/apache2"
    && properties["exePath"] == "apache2"
    && properties["groups"].contains("www-data");

Privilégios

Os privilégios garantem acesso a interfaces específicas. Alguns pontos de extremidade são RESTful e podem ser expressos puramente como um caminho. Outros são influenciados por parâmetros de consulta.

Os privilégios são definidos com um name, um path e um Set opcional de queryParameters:

"privileges": [
    {
        "name": "GoalState",
        "path": "/machine",
        "queryParameters": {"comp": "goalstate"}
    },
    {
        "name": "config",
        "path": "/machine",
        "queryParameters": {"comp": "config"}
    }
]

Regras de comparação

  • A correspondência de cadeia de caracteres não diferencia maiúsculas de minúsculas
  • Se nenhum parâmetro de consulta for especificado, o privilégio concederá acesso a todos os valores possíveis nesse caminho

defaultAccess Réguas

Os modos de acesso padrão são usados para bloquear lentamente uma carga de trabalho e simplificar a criação de regras no caso em que apenas pontos de extremidade específicos são de interesse para restringir o acesso.

Modo defaultAccess Comportamento
Deny Se não houver nenhuma atribuição explícita autorizando o aplicativo convidado para o recurso solicitado, a solicitação será rejeitada.
Allow Se não existirem regras para um privilégio específico, então o acesso será permitido por padrão. Se houver algum privilégio para esse recurso, o comportamento será revertido para negação padrão para esse recurso.
  • Se os parâmetros de consulta forem fornecidos, a pergunta "é um privilégio definido?" para determinar se defaultAccess aplica se torna: "Alguma regra corresponde a esse caminho + cada parâmetro de consulta especificado na regra está presente + correspondências na solicitação?". Parâmetros de consulta extras são ignorados nesta avaliação.
  • A solicitação será rejeitada se chaves de parâmetro de consulta duplicadas em uma solicitação forem inválidas

Escrevendo regras

Especificar uma lista de permissões por meio de regras RBAC é opcional. Se um for especificado, porém, todos os campos deverão ser fornecidos. (Por exemplo, se você não tivesse nenhum roles para definir, você ainda assim forneceria a matriz vazia).

A maneira mais fácil de gerar regras é primeiro executar o MSP no modo Audit, e em seguida, usar os logs de auditoria para gerar regras.

Expansão de esquema do IMDS (Serviço de Metadados de Instância Completa) /exemplo da subseção de regras:

{
  "defaultAccess": "allow",
  "mode": "enforce",
  "rules": {
    "privileges": [
      {
        "name": "Msi",
        "path": "/metadata/identity/oauth2/token"
      }
    ],
    "roles": [
      {
        "name": "MyWebApp",
        "privileges": [
          "Msi"
        ]
      }
    ],
    "identities": [
      {
        "name":"MyWebApp1",
        "processName":"WebApp1"
      }
    ],
    "roleAssignments": [
      {
        "role": "MyWebApp",
        "identities": [
          "MyWebApp1"
        ]
      }
    ]
  },
  "id": "D/uTRPye9b9xSUCRIgfRDF41zeY="
}

Expansão completa do esquema wireserver/exemplo da subseção de regras:

{
  "defaultAccess": "allow",
  "mode": "enforce",
  "rules": {
    "privileges": [
      {
        "name": "GoalState",
        "path": "/machine",
        "queryParameters": {
          "comp": "goalstate"
        }
      }
    ],
    "roles": [
      {
        "name": "Provisioning",
        "privileges": [
          "GoalState"
        ]
      }
    ],
    "identities": [
      {
        "name": "WinPA",
        "exePath": "C:\\Windows\\OEM\\Unattend.wsf.exe",
        "processName": "winpa.exe",
        "userName": "SYSTEM"
      }
    ],
    "roleAssignments": [
      {
        "role": "Provisioning",
        "identities": [
          "WinPA"
        ]
      }
    ]
  },
  "id": "D/uTRPye9b9xSUCRIgfRDF41zeY="
}

Configurações implícitas + padrão

A seguinte definição de RBAC é aplicada como comportamento padrão para regras de acesso de defesa detalhada que existiam antes do MSP:

{
    "imds": {
        "defaultAccess": "Allow",
        "mode": "Disabled",
    },
    "wireServer": {
        "defaultAccess": "Allow",
        "mode": "Enforce",
    }
}

Lembre-se, porém, o Wireserver só permite o acesso de processos administrador/raiz. O motivo defaultAccess ainda é Allow aqui porque essa regra não é configurável pelo usuário. Está incorporado ao cálculo do GPA. O GPA verifica se o cliente é um usuário administrador antes de avaliar as regras do RBAC para uma solicitação do Wireserver. Se o cliente não for um usuário administrador, a solicitação será rejeitada imediatamente.