Questão de Segurança da Informação — Controles de segurança — FGV 2022
Segurança da Informação›Controles de segurança
Código
fg056749
Banca
FGV
Órgão
TJ-TO
Ano
2022
Nível
Médio
Cargo
Técnico Judiciário - Informática
Um Time de Tecnologia da Informação (TTI) de um tribunal de justiça recebeu a demanda de disponibilizar o acesso a algumas partes do Sistema Web de Acompanhamento de Processos (SAProc) por meio de um aplicativo para dispositivos móveis. Somente usuários internos, que já possuam acesso ao sistema Web SAProc, poderão utilizar o novo aplicativo. Atualmente, o SAProc utiliza o protocolo OAuth2 como framework de autorização entre a aplicação web que atua no front-end e a API RESTFul que atua no back-end.Em função da premissa de uso do OAuth2 pelo novo aplicativo, o TTI deverá:
Aaplicar Refresh Tokens não expiráveis;
Bfazer uso de Access Tokens para acesso a API RESTful;
Cconsiderar o Resource Owner como hospedeiro da API RESTful;
Dutilizar um Token Endpoint para armazenar os autorizações de acesso;
Econfigurar o Resource Server como o responsável por gerar autorizações de acesso a API RESTful.
Revelar gabarito e comentário▾
GabaritoB — fazer uso de Access Tokens para acesso a API RESTful;
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
OAuth 2.0 em dispositivos móveis
Gabarito: letra B. No OAuth 2.0, o cliente (aplicativo móvel) obtém um Access Token do servidor de autorização e o utiliza para acessar os recursos protegidos no Resource Server (API RESTful). Essa é a essência do fluxo de autorização – o Access Token é a credencial que prova a permissão de acesso.
As demais alternativas incorrem em erros conceituais típicos da banca ao inverter ou atribuir incorretamente as responsabilidades dos componentes do OAuth 2.0.
Alternativa A — ❌ Incorreta
Afirma que devem ser aplicados Refresh Tokens não expiráveis. Na prática, Refresh Tokens possuem prazo de validade e podem ser revogados por questões de segurança. Tokens de longa duração ou sem expiração são considerados prática insegura, conforme as recomendações da OWASP e do RFC 6749.
Alternativa B — ✅ Correta ⟵ GABARITO
O Access Token é o meio padrão para acessar a API RESTful no OAuth 2.0. O cliente envia o token no cabeçalho de autorização das requisições HTTP, e o Resource Server valida sua assinatura e escopos antes de liberar os recursos.
Alternativa C — ❌ Incorreta
Considera o Resource Owner como hospedeiro da API RESTful. O Resource Owner é o usuário final que autoriza o acesso aos seus dados, e não o servidor que hospeda a API. O hospedeiro da API é o Resource Server, que contém os recursos protegidos.
Alternativa D — ❌ Incorreta
Diz que o Token Endpoint serve para armazenar as autorizações de acesso. Na verdade, o Token Endpoint é um ponto de acesso do servidor de autorização onde o cliente obtém o token (Access Token e, opcionalmente, Refresh Token) mediante comprovação da autorização concedida pelo Resource Owner. Ele não armazena autorizações; a autorização é representada pelo próprio token emitido.
Alternativa E — ❌ Incorreta
Configura o Resource Server como responsável por gerar autorizações de acesso. O papel do Resource Server é validar o Access Token e servir os recursos – não gerá-los. A geração dos tokens é feita pelo Authorization Server (servidor de autorização).
NÃO CAIA NESSA!
A banca explora a confusão entre os papéis do Authorization Server e do Resource Server, e entre Access Token e Refresh Token. Guarde: quem emite tokens é o Authorization Server; quem consome tokens para liberar recursos é o Resource Server. Refresh Token é útil para obter novos Access Tokens, mas tem prazo de validade.
MNEMÔNICO
CID
CConfidencialidade (dados acessíveis só a quem é autorizado)IIntegridade (dados exatos, consistentes e não alterados indevidamente)DDisponibilidade (informação/sistemas acessíveis quando necessário)