Autenticação e autorização para os 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 gerenciados protegidos que usam o Microsoft Entra ID, um provedor de identidade global que dá suporte ao OAuth 2.0.
Para que os Serviços de Dados de Integridade do Azure acessem os 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 no Microsoft Entra ID 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
Os usuários autenticados e 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 Integridade do Azure fornece estas funções:
- Leitor de Dados FHIR: ler e pesquisar os dados FHIR.
- Gravação de Dados FHIR: ler, gravar e excluir suavemente os dados FHIR.
- Exportador de Dados FHIR: ler e exportar os dados (operador $export).
- Importador de Dados FHIR: ler e importar os dados (operador $import).
- Colaborador de Dados FHIR: execute todas as operações do plano de dados.
- Conversor de Dados FHIR: use o conversor para executar a conversão de dados.
- Usuários do FHIR SMART: permite que o usuário leia e grave os dados FHIR de acordo com as Especificações do SMART IG V1.0.0.
O serviço DICOM® nos Serviços de Dados de Integridade do Azure fornece as seguintes funções:
- Proprietário de Dados DICOM: ler, gravar e excluir os dados DICOM.
- Leitura de Dados DICOM: ler os dados DICOM.
O serviço MedTech não requer as funções de aplicativo, mas depende do Receptor de Dados dos Hubs de Eventos do Azure para recuperar os dados armazenados no hub de eventos da assinatura da sua organização.
Autorização
Depois de terem as funções de aplicativo apropriadas concedidas, os usuários autenticados e os aplicativos cliente poderão acessar os Serviços de Dados de Saúde do Azure obtendo um token de acesso válido emitido pelo Microsoft Entra ID e poderão executar operações definidas pelas funções de aplicativo.
- Quanto ao serviço FHIR, o token de acesso é específico para o serviço ou recurso.
- Quanto ao serviço DICOM, o token de acesso é concedido ao recurso
dicom.healthcareapis.azure.com, não a um serviço específico. - Quanto ao serviço MedTech, o token de acesso não é necessário porque ele não é exposto aos usuários ou aplicativos cliente.
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 do cliente.
Veja como um token de acesso dos Serviços de Dados de Integridade do Azure é obtido usando o fluxo de código de autorização:
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 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. O Microsoft Entra permite que esse código de autorização seja retornado para uma URL de resposta registrada configurada no registro do aplicativo cliente.
O aplicativo cliente troca o código de autorização por um token de acesso no ponto de extremidade de token do 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).
O cliente faz uma solicitação para os Serviços de Dados de Integridade do Azure, por exemplo, uma solicitação
GETpara 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.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á 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, pois não há usuários envolvidos na autenticação. Portanto, ele é diferente do fluxo de código de autorização destas 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 pelas permissões de aplicativo.
Token de acesso
O token de acesso é uma coleção de propriedades (declarações) Base64 codificada que transmite informações sobre a identidade, as funções e os privilégios do cliente concedidos ao usuário ou ao cliente.
Os Serviços de Dados de Integridade do Azure normalmente esperam um Token Web JSON. 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.
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 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 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. Um recurso pode rejeitar o token antes desse período, por exemplo, se for necessária uma alteração na autenticação ou se for detectada uma revogação de token. |
| aio | E2ZgYxxx | Uma declaração interna usada pelo Microsoft Entra ID 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 Microsoft Entra ID. |
| 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. Em vez disso, se a declaração não estiver presente, isso significa que o valor de iss pode ser usado. Quanto às 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. |
| 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 correlacionam os 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. Deve ser ignorado. |
| sub | Por exemplo, tenantid | O item mais importante 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 nem reusado. O assunto é um identificador de paridade - ele é exclusivo de 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 do assunto. Talvez você não queira esse resultado dependendo da 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 faz parte. Para contas corporativas e de estudante, o GUID é a ID de locatário imutável da organização à qual o usuário pertence. Quanto às 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. 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 no Visual Studio Code, PowerShell, CLI, curl e as bibliotecas de autenticação do Microsoft Entra.
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 em repouso quando os dados são persistidos no armazenamento de dados.
- O serviço DICOM fornece criptografia de dados em repouso quando os dados de imagem, incluindo metadados inseridos, são mantidos no armazenamento de dados. Quando os metadados são extraídos e persistidos no serviço FHIR, eles são criptografados automaticamente.
- Depois do mapeamento e da normalização dos dados, o serviço MedTech persiste nas mensagens do dispositivo para o serviço FHIR, que é criptografado automaticamente. Nos casos em que as mensagens do dispositivo são enviadas aos Hubs de Eventos do Azure, que usam o Armazenamento do Azure para armazenar os dados, os dados são criptografados automaticamente com a Criptografia do Serviço de Armazenamento do Azure (SSE).
Próximas etapas
Usar o Azure Active Directory B2C para conceder acesso ao serviço FHIR