Segurança da Informação - Parte 2

Primeiro entre na casa, depois entre no cômodo

      No primeiro artigo sobre Segurança da Informação, conversamos sobre o fato de que tudo começa com a criação das roles.
      Com relação a boas práticas, falamos também que deve-se atribuir uma role a um grupo e não diretamente a um usuário.
      A terceira informação sobre esse assunto pode parecer um easter egg mas você - leitor(a) atento(a) - já pegou no subtítulo desse artigo: "Primeiro entre na casa, depois no cômodo". Anote a frase em um post-it aí que em breve a gente conversa sobre isso.


Enviei meu Aplicativo para Homologação e não consigo inserir, ler, atualizar ou excluir meus registros. O que aconteceu?

Superman

      Quando um dev está desenvolvendo a aplicação no ambiente de desenvolvimento, ele é administrador daquele app.
      É possível fazer tudo. Pode criar, modificar e apagar qualquer tipo de componente.
      Tem acesso a todos os campos de todas as tabelas. Ele é tipo o Superman.



Clark Kent

      As coisas mudam um pouco quando um app é promovido para o ambiente de Homologação.
      Lá apesar do dev ter um usuário e senha para fazer login, ele não tem mais super poderes.
      É tipo o Clark Kent no escritório do Planeta Diário, sabe?




Veja se você está fazendo isso errado

      Ao abrir uma tabela no Studio há uma aba chamada Application Access.
      Se você clicar em Can create achando que está permitindo ao seu usuário a criação de registros em Homologação ou Produção para tudo... você está fazendo isso errado.
      De maneira similar, clicar em Can update não irá permitir ao seu usuário editar um registro dessa tabela em Homologação/Produção.

application access

      Mas então que tipo de acesso é esse afinal?
      Ao deixar checked (verdadeiro) essas opções, você está dizendo a plataforma que outros aplicativos podem realizar essas operações nos registros da sua tabela. Isso é chamado de autorização cross-scope.


É agora que o papo fica bom

      Entendi... não é alí que eu mexo. Conte-me mais...

      Na edição da tabela dentro do Studio, clique na aba Controls. Rolando a tela para baixo veremos que há uma role especificada para o campo "User role".

controls

      Outra coisa a ser observada é a mensagem de ajuda que explica:
      Regras de Segurança (ACLs) são exigidas caso alguém além do administrador precise trabalhar com essa tabela. Criar regras de segurança padrão irá conceder acesso completo a esta tabela para qualquer um que tenha a user role que você especificar.

      Quando o seu usuário logar para fazer os testes na instância de Homologação ele não terá a role de administrador, concorda?
      Como ele não é admin, precisará ter essa User role atribuída para que possa manipular os registros da sua tabela.

      Coisas importantes que você deve fazer:
  1. Criar um Grupo* na instância de Homologação;
  2. Atribuir a User role da sua tabela a esse Grupo; e
  3. Colocar o seu usuário testador dentro desse grupo.
      Ao colocar o usuário testador dentro do Grupo que contém a User role especificada para a sua tabela, ele herdará essa role.


E os Access Controls com isso?

      No Studio, perceba que no Application Explorer existe a navegação para Access Control > Access Controls.
      Quando criamos uma tabela, o Studio cria automaticamente quatro registros nessa seção. Abaixo está o registro da operação create (inclusão) da minha tabela.

access controls


      Operação: create
      Name: (Nome da sua tabela) | -- None --
      Requires role: (A mesma User role definida para a sua tabela)

      É nesse registro que a gente consegue "amarrar tudo". Vem comigo:

  • A operação create indica que este registro está permitindo a inclusão de registros para a tabela especificada no campo Name;
  • No campo Name especificamos o nome da tabela em que será permitida essa operação;
  • O -- None -- ao lado do nome da tabela indica que vamos permitir a operação em todos os campos da tabela;
  • A tabela Requires role lá embaixo informa qual role um Usuário precisa ter para que ele receba o acesso à operação definida nesse registro.

          A role definida aqui é o mesmo nome tanto da role definida na configuração da nossa tabela quanto aquela atribuída ao Grupo de Usuários criado na instância de Homologação. Por conta disso, todo usuário que for incluído no Grupo vai herdar essa role e poderá inserir registros na tabela.


    Quero permitir que um Usuário leia os registros da minha tabela. É muito complicado?

          Para cada operação sobre a sua tabela (leitura, inserção, alteração ou exclusão) haverá 1 (um) Access Control.
          Vejamos um Access Control concedendo a leitura de registros da sua tabela:

    access controls


          Operação: read
          Name: (Nome da sua tabela) | -- None --
          Requires role: (A mesma User role definida para a sua tabela)

          Perceba que nesse registro de Access Control que permite a leitura de registros a única coisa que muda é a operação.

          Agora você já pegou a ideia... Precisará de outros dois registros de operações update e delete para permitir, respectivamente, a alteração e a exclusão de registros.

    __________
    * Um Grupo de Usuários não faz parte dos arquivos de uma aplicação. Por esse motivo ele deve ser criado em todas as instâncias e de preferência com o mesmo nome.
    Para trabalhar com registros de ACL antes deve-se elevar funções para security admin. Clique em User menu > Elevate Roles. Marque a role security_admin e clique em Ok.

    Voltar