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

Autenticação

Os Serviços de Dados de Saúde do Azure são uma coleção de serviços geridos seguros que utilizam o Microsoft Entra ID, um fornecedor de identidade global que suporta OAuth 2.0.

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

Os aplicativos cliente são registrados na ID do Microsoft Entra e podem ser usados para acessar os Serviços de Dados de Saúde do Azure. Os controles de acesso aos dados do usuário são feitos nos aplicativos ou serviços que implementam a lógica de negócios.

Funções da aplicação

Os usuários autenticados e os aplicativos cliente dos Serviços de Dados de Integridade do Azure devem ser atribuídos à função de aplicativo adequada.

O serviço FHIR® nos Serviços de Dados de Saúde do Azure fornece estas funções:

• FHIR Data Reader: Leia e pesquise dados FHIR.
• FHIR Data Writer: Leia, escreva e elimine suavemente dados FHIR.
• FHIR Data Exporter: Ler e exportar dados (operador $export).
• FHIR Data Importer: Leia e importe (operador $import dados).
• FHIR Data Contributor: Execute todas as operações do plano de dados.
• FHIR Data Converter: Use o conversor para executar a conversão de dados.
• FHIR SMART User: Permite ao usuário ler e escrever dados FHIR de acordo com as especificações SMART IG V1.0.0.

O serviço DICOM® nos Serviços de Dados de Saúde do Azure fornece as seguintes funções:

• Proprietário de dados DICOM: Leia, escreva e exclua dados DICOM.
• Dados DICOM Ler: Leia os dados DICOM.

O serviço MedTech não requer funções de aplicativo, mas depende do Recetor de Dados dos Hubs de Eventos do Azure para recuperar dados armazenados no hub de eventos da assinatura da sua organização.

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 Saúde do Azure obtendo um token de acesso válido emitido pela ID do Microsoft Entra e executar operações específicas definidas pelas funções do 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 recurso, não a dicom.healthcareapis.azure.com um serviço específico.
• Para o serviço MedTech, o token de acesso não é necessário porque não está exposto aos usuários ou aplicativos clientes.

Etapas para autorização

Há duas maneiras comuns de obter um token de acesso, descritas em detalhes pela documentação do Microsoft Entra: fluxo de código de autorização e fluxo de credenciais de 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 do Microsoft Entra. O Microsoft Entra ID redireciona o cliente para uma página de entrada onde o usuário se autentica usando 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. O Microsoft Entra-only 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 para um token de acesso no ponto de extremidade do token Microsoft Entra. 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 Saúde 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 HTTP solicitação, por exemplo, Authorization: Bearer xxx.

4. Os Serviços de Dados de Integridade do Azure validam se o token contém declarações apropriadas (propriedades no token). Se for válido, conclui o pedido e devolve os 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 para um recurso, o recurso impõe que o próprio aplicativo tenha autorização para executar uma ação, uma vez que não há nenhum usuário envolvido na autenticação. Portanto, é 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 através de permissões de aplicativo.

Token de acesso

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

Os Serviços de Dados de Saúde do Azure normalmente esperam um Token Web JSON. É composto por três partes:

• Cabeçalho
• Carga útil (as reclamações)
• Assinatura, como mostra a imagem. Para obter mais informações, consulte Tokens de acesso do Azure.

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

Tipo de reclamação	Valor	Notas
aud	https://xxx.fhir.azurehealthcareapis.com	Identifica o destinatário pretendido do token. No id_tokens, o público é a ID do Aplicativo do seu aplicativo, atribuída ao seu aplicativo 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 serviço de token de segurança (STS) que constrói e retorna o token e o locatário do Microsoft Entra no qual o usuário foi autenticado. Se o token foi emitido pelo ponto de extremidade v2.0, o URI termina em /v2.0. O GUID que indica que o usuário é um usuário consumidor de uma 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 para este token.
NBF	(carimbo de data/hora)	A reivindicação "nbf" (não antes) identifica o tempo antes do qual o JWT NÃO DEVE ser aceito para processamento.
exp	(carimbo de data/hora)	A reivindicação "exp" (tempo de expiração) identifica o tempo de expiração no qual ou após o qual o JWT não deve ser aceito para processamento. Um recurso pode rejeitar o token antes desse período, por exemplo, se uma alteração na autenticação for necessária ou se uma revogação de token for detetada.
AIO	E2ZgYxxx	Uma declaração interna usada pelo Microsoft Entra ID para registrar dados para reutilização de token. Deve ser ignorado.
Appid	e97e1b8c-xxx	O ID do aplicativo do cliente usando o token. O aplicativo pode agir como ele mesmo ou em nome de um usuário. A ID do aplicativo normalmente representa um objeto de aplicativo, mas também pode representar um objeto principal de serviço na ID do Microsoft Entra.
Appidacr	1	Indica como o cliente foi autenticado. Para um cliente público, o valor é 0. Se o ID do cliente e o segredo do cliente forem usados, o valor será 1. Se um certificado de cliente foi usado para autenticação, o valor é 2.
Deslocados Internos	https://sts.windows.net/{tenantid}/	Regista o fornecedor de identidade que autenticou o requerente do token. Esse valor é idêntico ao valor da declaração do Emissor, a menos que a conta do usuário não esteja no mesmo locatário que o emissor - convidados, por exemplo. Se a reivindicação não estiver presente, significa que o valor do ISS pode ser usado em vez disso. Para contas pessoais que estão sendo usadas em um contexto organizacional (por exemplo, uma conta pessoal convidada para um locatário do Microsoft Entra), a declaração idp pode ser 'live.com' ou um URI STS contendo o locatário da conta da Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
Oide	Por exemplo, tenantid	O identificador imutável para um objeto no sistema de identidade da Microsoft, neste caso, uma conta de usuário. Esse ID identifica exclusivamente o usuário entre aplicativos - dois aplicativos diferentes que entram 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 o oid permite que vários aplicativos correlacionem usuários, o escopo do perfil é necessário para receber essa declaração. Nota: Se existir um único utilizador em vários inquilinos, o utilizador contém um ID de objeto diferente em cada inquilino - são consideradas contas diferentes, apesar de o utilizador iniciar sessão em cada conta com as mesmas credenciais.
RH	0.ARoxxx	Uma declaração interna usada pelo Azure para revalidar tokens. Deve ser ignorado.
sub	Por exemplo, tenantid	A entidade sobre a qual o token afirma 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 de pares - é exclusivo para um ID de aplicativo específico. 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 assunto. Você pode não querer esse resultado dependendo de sua arquitetura e requisitos de privacidade.
TID	Por exemplo, tenantid	Um GUID que representa o locatário do Microsoft Entra do qual o usuário é. Para contas corporativas e de estudante, o GUID é o 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.
ITU	bY5glsxxx	Uma declaração interna usada pelo Azure para revalidar tokens. 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 Postman, a extensão de cliente REST no Visual Studio Code, PowerShell, CLI, curl e as bibliotecas de autenticação do Microsoft Entra.

Encriptação

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

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

Próximos passos

Implantar o espaço de trabalho dos Serviços de Dados de Saúde do Azure usando o portal do Azure

Usar o Azure Ative Directory B2C para conceder acesso ao serviço FHIR

Nota

FHIR® é uma marca registada da HL7 e é utilizada com a permissão da HL7.

DICOM® é a marca registrada da National Electrical Manufacturers Association para suas publicações de padrões relacionados a comunicações digitais de informações médicas.