Autenticação e autorização para os Serviços de Dados de Saúde do Azure

  • Artigo

Autenticação

Os Serviços de Dados de Integridade do Azure são uma coleção de serviços gerenciados protegidos usando o Azure Active Directory (Azure AD), um provedor de identidade global que dá suporte ao OAuth 2.0.

Para que os Serviços de Dados de Integridade do Azure acessem recursos do Azure, como contas de armazenamento e hubs de eventos, você deve habilitar a identidade gerenciada do sistema e conceder permissões adequadas à identidade gerenciada. Para obter mais informações, consulte Identidades gerenciadas do Azure.

Os Serviços de Dados de Integridade do Azure não dão suporte a outros provedores de identidade. No entanto, você pode usar seu próprio provedor de identidade para proteger aplicativos e permitir que eles interajam com os Serviços de Dados de Integridade gerenciando aplicativos cliente e controles de acesso a dados do usuário.

Os aplicativos cliente são registrados no Azure AD e podem ser usados para acessar os Serviços de Dados de Integridade do Azure. Os controles de acesso a dados do usuário são feitos nos aplicativos ou serviços que implementam a lógica de negócios.

Funções de aplicativo

Usuários autenticados e aplicativos cliente dos Serviços de Dados de Integridade do Azure devem ser concedidos com funções de aplicativo adequadas.

O serviço FHIR dos Serviços de Dados de Integridade do Azure fornece as seguintes funções:

  • Leitor de Dados FHIR: pode ler (e pesquisar) dados FHIR.
  • FHIR Data Writer: pode ler, gravar e excluir dados FHIR.
  • Exportador de Dados FHIR: pode ler e exportar dados (operador $export).
  • Importador de Dados FHIR: pode ler e importar dados (operador $import).
  • Colaborador de Dados FHIR: pode executar todas as operações do plano de dados.
  • Conversor de dados FHIR: pode usar o conversor para executar a conversão de dados.
  • Usuário INTELIGENTE FHIR: a função permite que o usuário leia e escreva dados FHIR de acordo com as especificações do SMART IG V1.0.0.

O serviço DICOM dos Serviços de Dados de Integridade do Azure fornece as seguintes funções:

  • Proprietário de dados DICOM: pode ler, gravar e excluir dados DICOM.
  • Leitura de dados DICOM: pode ler dados DICOM.

O serviço MedTech não requer funções de aplicativo, mas depende do "Hubs de Eventos do Azure Data Receiver" para recuperar dados armazenados no hub de eventos da assinatura do cliente.

Autorização

Depois de serem concedidos com funções de aplicativo adequadas, os usuários autenticados e os aplicativos cliente podem acessar os Serviços de Dados de Integridade do Azure obtendo um token de acesso válido emitido por Azure AD e executar operações específicas definidas pelas funções de aplicativo.

  • Para o serviço FHIR, o token de acesso é específico para o serviço ou recurso.
  • Para o serviço DICOM, o token de acesso é concedido ao dicom.healthcareapis.azure.com recurso, não a um serviço específico.
  • Para o serviço MedTech, o token de acesso não é necessário porque ele não está exposto aos usuários ou aplicativos cliente.

Etapas para autorização

Há duas maneiras comuns de obter um token de acesso, descrito detalhadamente pela documentação do Azure AD: fluxo de código de autorização e fluxo de credenciais do cliente.

Veja como um token de acesso para os Serviços de Dados de Integridade do Azure é obtido usando o fluxo de código de autorização:

  1. O cliente envia uma solicitação para o ponto de extremidade de autorização Azure AD. Azure AD redireciona o cliente para uma página de entrada em que o usuário se autentica usando as credenciais apropriadas (por exemplo: nome de usuário e senha ou uma autenticação de dois fatores). Após a autenticação bem-sucedida, um código de autorização é retornado ao cliente. Azure AD só permite que esse código de autorização seja retornado para uma URL de resposta registrada configurada no registro do aplicativo cliente.

  2. O aplicativo cliente troca o código de autorização por um token de acesso no ponto de extremidade do token Azure AD. Quando o aplicativo cliente solicita um token, o aplicativo pode ter que fornecer um segredo do cliente (que você pode adicionar durante o registro do aplicativo).

  3. O cliente faz uma solicitação aos Serviços de Dados de Integridade do Azure, por exemplo, uma GET solicitação para pesquisar todos os pacientes no serviço FHIR. A solicitação inclui o token de acesso em um cabeçalho de solicitaçãoHTTP, por exemplo, Authorization: Bearer xxx.

  4. Os Serviços de Dados de Integridade do Azure validam que o token contém declarações apropriadas (propriedades no token). Se for válido, ele concluirá a solicitação e retornará dados ao cliente.

No fluxo de credenciais do cliente, as permissões são concedidas diretamente ao próprio aplicativo. Quando o aplicativo apresenta um token a um recurso, o recurso impõe que o próprio aplicativo tenha autorização para executar uma ação, pois não há nenhum usuário envolvido na autenticação. Portanto, ele é diferente do fluxo de código de autorização das seguintes maneiras:

  • O usuário ou o cliente não precisa entrar interativamente.
  • O código de autorização não é necessário.
  • O token de acesso é obtido diretamente por meio de permissões de aplicativo.

Token de acesso

O token de acesso é uma coleção de propriedades (declarações) codificada em Base64 assinada que transmite informações sobre a identidade, as funções e os privilégios do cliente concedidos ao usuário ou ao cliente.

Normalmente, os Serviços de Dados de Integridade do Azure esperam um token Web JSON. Ele consiste em três partes:

  • Cabeçalho
  • Conteúdo (as declarações)
  • Assinatura, conforme mostrado na imagem. Para obter mais informações, consulte Tokens de acesso do Azure.

Assinatura de token da Web JASON.

Use ferramentas online como https://jwt.ms para exibir o conteúdo do token. Por exemplo, você pode exibir os detalhes das declarações.

Tipo de declaração Valor Observações
aud https://xxx.fhir.azurehealthcareapis.com Identifica o destinatário pretendido do token. Em id_tokens, o público-alvo é a ID de Aplicativo de seu aplicativo, atribuída a ele no portal do Azure. Seu aplicativo deve validar esse valor e rejeitar o token se o valor não corresponder.
iss https://sts.windows.net/{tenantid}/ Identifica o STS (Serviço de Token de Segurança) que constrói e retorna o token e o locatário do Azure AD no qual o usuário foi autenticado. Se o token tiver sido emitido pelo ponto de extremidade v2.0, o URI termina em /v2.0. O GUID que indica que o usuário é um consumidor da conta da Microsoft é 9188040d-6c67-4c5b-b112-36a304b66dad. Seu aplicativo deve usar a parte GUID da declaração para restringir o conjunto de locatários que podem entrar no aplicativo, se for aplicável.
iat (carimbo de data/hora) "Emitido em" indica quando ocorreu a autenticação desse token.
nbf (carimbo de data/hora) A declaração "nbf" (não antes) identifica a hora antes da qual o JWT NÃO DEVE ser aceito para processamento.
exp (carimbo de data/hora) A declaração "exp" (hora de expiração) identifica a hora de expiração ou a hora após ela na qual o JWT NÃO DEVE ser aceito para processamento. Observe que um recurso pode rejeitar o token antes desse momento, por exemplo, se uma alteração na autenticação for necessária ou uma revogação de token tiver sido detectada.
aio E2ZgYxxx Uma declaração interna usada pelo Azure AD para registrar os dados para reutilização de token. Deve ser ignorado.
appid e97e1b8c-xxx A ID do aplicativo do cliente que usa o token. O aplicativo pode agir como ele próprio ou em nome de um usuário. A ID do aplicativo normalmente representa um objeto de aplicativo, mas também pode representar um objeto de entidade de serviço no AD do Azure.
appidacr 1 Indica como o cliente foi autenticado. Para um cliente público, o valor é 0. Se a ID do cliente e o segredo do cliente são usados, o valor é 1. Se um certificado do cliente tiver sido usado para autenticação, o valor será 2.
idp https://sts.windows.net/{tenantid}/ Registra o provedor de identidade que autenticou a entidade do token. Esse valor é idêntico ao valor da declaração do Emissor, a menos que a conta de usuário não esteja no mesmo locatário que o emissor – convidados, por exemplo. Se a declaração não estiver presente, isso significa que o valor de iss pode ser usado em vez disso. Para contas pessoais que estão sendo usadas em um contexto organizacional (por exemplo, um conta pessoal convidado para um locatário Azure AD), a declaração de idp pode ser 'live.com' ou um URI STS que contém o locatário da conta microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
oid Por exemplo, tenantid O identificador imutável de um objeto do sistema de identidade da Microsoft, nesse caso, uma conta de usuário. Essa ID identifica exclusivamente o usuário entre aplicativos – dois aplicativos diferentes que estão entrando no mesmo usuário recebem o mesmo valor na declaração oid. O Microsoft Graph retorna essa ID como a propriedade ID de uma determinada conta de usuário. Como a oid permite que vários aplicativos correlacionem usuários, o escopo do perfil é necessário para receber essa declaração. Observação: se um único usuário existir em vários locatários, o usuário conterá uma ID de objeto diferente em cada locatário – elas serão consideradas contas diferentes, mesmo que o usuário faça logon em cada conta com as mesmas credenciais.
rh 0.ARoxxx Uma declaração interna usada pelo Azure para revalidar tokens. Ele deve ser ignorado.
sub Por exemplo, tenantid O princípio sobre o qual o token declara informações, como o usuário de um aplicativo. Esse valor é imutável e não pode ser reatribuído ou reutilizado. O assunto é um identificador par - é exclusivo para uma ID de aplicativo específica. Portanto, se um único usuário entrar em dois aplicativos diferentes usando duas IDs de cliente diferentes, esses aplicativos receberão dois valores diferentes para a declaração de entidade. Você pode ou não desejar esse resultado dependendo de seus requisitos de arquitetura e privacidade.
tid Por exemplo, tenantid Um GUID que representa o locatário do Azure AD do qual o usuário é proveniente. Para contas corporativas e de estudante, o GUID é a ID de locatário imutável da organização à qual o usuário pertence. Para contas pessoais, o valor é 9188040d-6c67-4c5b-b112-36a304b66dad. O escopo do perfil é necessário para receber essa declaração.
uti bY5glsxxx Uma declaração interna usada pelo Azure para revalidar tokens. Ele deve ser ignorado.
ver 1 Indica a versão do token.

O token de acesso é válido por uma hora por padrão. Você pode obter um novo token ou renová-lo usando o token de atualização antes que ele expire.

Para obter um token de acesso, você pode usar ferramentas como o Postman, a extensão cliente REST em Visual Studio Code, PowerShell, CLI, curl e as bibliotecas de autenticação Azure AD.

Criptografia

Quando você cria um novo serviço dos Serviços de Dados de Integridade do Azure, seus dados são criptografados usando chaves gerenciadas pela Microsoft por padrão.

  • O serviço FHIR fornece criptografia de dados inativos quando os dados são persistidos no armazenamento de dados.
  • O serviço DICOM fornece criptografia de dados inativos quando os dados de geração de imagens, incluindo metadados inseridos, são persistidos no armazenamento de dados. Quando os metadados são extraídos e persistidos no serviço FHIR, eles são criptografados automaticamente.
  • O serviço MedTech, após o mapeamento e a normalização de dados, persiste as mensagens do dispositivo para o serviço FHIR, que é criptografado automaticamente. Nos casos em que as mensagens de dispositivo são enviadas para Hubs de Eventos do Azure, que usam o Armazenamento do Azure para armazenar os dados, os dados são criptografados automaticamente com a SSE (Criptografia do Serviço de Armazenamento do Azure).

Próximas etapas

Neste documento, você aprendeu a autenticação e a autorização dos Serviços de Dados de Integridade do Azure. Para saber como implantar uma instância dos Serviços de Dados de Integridade do Azure, confira

Implantar o workspace dos Serviços de Dados de Integridade do Azure usando o portal do Azure

FHIR® é uma marca registrada da HL7 e é usado com a permissão da HL7.