CAN – Controle de Acesso Nacional Exposição para TI Administração Regional

1. CAN – Controle de Acesso NacionalExposição para TI Administração Regional

2. DESCRIÇÃO/OBJETIVOS O Controle de Acesso Nacional foi desenvolvido para suprir a necessidade de maior segurança e controle da informação administrada pelos sistemas corporativos do SESC. • Podemos citar como principais objetivos: • - Garantir o acesso a informação e sua autenticidade de forma segura e confiável de acordo com o perfil de cada usuário. • - Integrar as informações do RH com TI de forma a manter atualizados os direitos de acesso. • Garantir ao Regional total liberdade na definição de sua política de segurança da informação oferecendo ferramenta e treinamento adequados. Mecanismo de segurança, controle e administração dos sistemas, o Controle de Acesso Nacional é composto por elementos internos a cada sistema, pelo CANWeb (site e aplicação), CANDesktop (aplicação) e ativador de sistemas.

3. DESCRIÇÃO/OBJETIVOS Há a possibilidade de personalização não só dos direitos de acesso a operações de um sistema como também, se necessário, aos seus registros. O CAN foi projetado de forma que seja possível atribuir funções diferentes a um grupo de usuários de acordo com o local (AR e UOP) de acesso do usuário. Foi criado um cadastro único de usuários vinculado ao CNRH de forma que ninguém em todo país tenha um login repetido, o que é necessário para sistemas que rodam na nossa Intranet. É a partir desse cadastro que são geradas as chaves de autenticação de usuário, necessárias ao ingresso do mesmo na base do regional. O CAN foi desenvolvido não só para aplicações web como também para aplicações desktop nas quais ele substituirá o controle de acesso anterior.

4. RECURSOS Senha criptografada O CAN utiliza algoritmo de criptografia de 64 bits para dados críticos. Expiração de senha O administrador pode habilitar ou desabilitar a expiração de senha para os usuários como forma de prover maior segurança. Controle de sessão e de tempo de inatividade Todo sistema tem um tempo de sessão programável que também é o tempo de inatividade máximo que o mesmo pode ter. Através da aplicação CAN é possível saber, dentre outras informações, quem está no sistema, a que horas entrou, de onde entrou, etc. Logon protegido Não é permitido errar a senha mais de 5 vezes em um certo período de tempo.

5. RECURSOS Senha segura - Classe para checar se a senha escolhida pelo usuário é insegura. Solução simples de modo a orientar o usuário na escolha da sua assinatura eletrônica. Já que estamos garantindo a confidencialidade da sua senha e promovendo uma série de recursos de segurança, precisamos conscientizar os usuários na definição da sua assinatura. O mecanismo está, atualmente, implementado de forma a avisar o usuário esclarecendo-o, no entanto sem impedi-lo de definir uma senha fácil. Comunicados por e-mail - Os administradores do CAN serão avisados quando pessoas são admitidas, demitidas e transferidas de modo a atualizar os direitos de acesso no CAN. Esse mesmo recurso de comunicados por e-mail poderá ser utilizado por qualquer sistema que deseje avisar os administradores do mesmo se um evento pré-definido ocorrer.

6. RECURSOS Mecanismo de implantação e atualização de sistemas baseados em XML Agora ficou mais fácil implantar e atualizar os dados referentes ao controle de acesso no regional. Não é mais preciso rodar scripts para inserção de dados, bastará que o administrador local importe o arquivo XML fornecido pelo Departamento Nacional. A partir deste momento, o administrador local é quem será o responsável por determinar os grupos a que cada usuário fará parte e os direitos de acesso concedidos a esses grupos. Aplicação Controle de Acesso separada dos sistemas de informação A administração do Controle de Acesso não é feita de dentro de cada sistema, em vez disso há uma aplicação exclusiva para esse fim e cada administrador de sistema precisará tê-la instalada em seu computador.

7. RECURSOS Login único para todo Brasil O CAN está totalmente vinculado ao CNRH(Cadastro Nacional de Recursos Humanos) no que diz respeito a identificação dos usuários. Ou seja, não existe usuário do CAN que não tenha origem no CNRH. Para habilitar um usuário no regional é preciso obter uma chave de ativação de usuário. Essas chaves podem ser obtidas diretamente pela Intranet do SESC no CANWeb ou mesmo por telefone(caso ocorra algum problema de comunicação). O procedimento de importação das chaves pelo regional é bastante simples e também funciona para importação em lote. Chaves de autenticação para todos usuários Os usuários são gerados a partir de uma pessoa(CNRH) e para uma Administração Regional. Essas informações, dentre outras, estão contidas na chave de autenticação do usuário, esta que é verificada no ato da importação e a cada login.

8. RECURSOS Controle de acesso a operações por grupos de usuários Os usuários só podem ter acesso as operações do sistema que o grupo de usuário a que ele pertence permite. Controle de acesso a registros por grupos de usuários Os usuários só podem ter acesso aos registros que o grupo de usuário a que ele pertence permite. Esse acesso pode ser personalizado como: ler registro, alterar registro, excluir registro, alterar direitos sobre registro.

9. RECURSOS Separação entre administrador do CAN e administrador de sistema de informação O administrador do CAN é o profissional de Tecnologia da Informação(TI) responsável pela segurança das informações e é ele quem dará direito aos administradores de sistemas. Para ser administrador de sistema, não há a necessidade de ser da área de TI, e os critérios funcionais e hierárquicos é que devem ser considerados para indicação dos mesmos. Eles serão os responsáveis por determinar as operações que cada grupo de usuários do seu sistema pode executar. Ativador de sistemas Permite que o administrador local defina a senha de acesso ao banco de dados para cada aplicação e a distribua aos usuários encapsulada na "Chave de ativação de sistemas"

10. RECURSOS Interface intuitiva O CAN para desktop, o CAN para web e o site do projeto foram desenvolvidos com a mesma concepção visual de modo a facilitar o entendimento. Portabilidade Devido a utilização de um framework de persistência de objetos o CAN pode ser compilado para funcionar sobre outros bancos de dados diferentes do DB2.

11. ALGUMAS DIFERENÇAS - Não há um cadastramento de usuário, gera-se um usuário a partir de uma pessoa do CNRH. Devido a centralização na obtenção do login (usuário), agora, cada pessoa ganha um ID único em todo o Brasil. - Não é permitido nem necessário a utilização de usuários genéricos como: “admin”, “caixa”, “atendente1”, etc... • O controle e administração do sistema não é feito de dentro do próprio. Existe aplicações exclusivas para este fim: • Para aplicações WEB: http://intranet.sesc.com.br/can • Para aplicações desktop: O CAN(desktop) - Os “Perfis” agora são chamados de “Grupos de Usuários”

12. ALGUMAS DIFERENÇAS Tela com os Grupos de Usuários (perfis) de um sistema

13. ALGUMAS DIFERENÇAS - As operações podem ser classificadas como operações de cadastro e operações de negócio. As do tipo cadastro são aquelas que permitem consultar, incluir, excluir e alterar registros, em uma determinada tabela do sistema, tal como existia nas classes do antigo controle de acesso. Já as operações de negócio são aquelas que permitem acesso a relatórios, pesquisas mais elaboradas e outras regras de negócio que não estão relacionadas a um cadastro comum.

14. ALGUMAS DIFERENÇAS Cadastro de operações, definido pelos desenvolvedores do sistema.

15. ALGUMAS DIFERENÇAS - O conceito "Classe" foi modificado. No novo controle de acesso não existe mais "Classe de Tarefas". Em seu lugar foi criado um conceito mais flexível de "Grupo de Operações". O desenvolvedor pode criar quantos grupos julgar necessário para a melhor organização das operações. Com o uso dos grupos mantêm-se as facilidades de unir e localizar operações próximas funcionalmente, ao mesmo tempo em que permite compartilhar uma mesma operação mais genérica.

16. ALGUMAS DIFERENÇAS Telas do antigo Controle de Acesso: Acima temos o cadastro de classes e ao lado podemos ver a tela onde definia-se o que cada perfil podia realizar.

17. ALGUMAS DIFERENÇAS Tela onde os desenvolvedores organizam as operações do sistema. Pode-se ver a classificação definida no projeto.

18. ALGUMAS DIFERENÇAS Aqui temos as operações relacionadas ao grupo de usuários (perfil)MKT-DN(Marketing de relacionamento DN)

19. ALGUMAS DIFERENÇAS A mesma tela anterior no CANWeb (Intranet)

20. ALGUMAS DIFERENÇAS - CAR - Agora há a possibilidade de associar um registro qualquer a um ou mais grupos de usuário, o que permite controlar o direito de acesso (consulta, alteração, exclusão) sobre o registro individualmente. O CAR, Controle de Acesso a Registro, deverá ser usado por aplicações que necessitem controlar o acesso sobre registros de uma ou mais tabelas. Ele possibilita, por exemplo, que um grupo de usuário “A” tenha permissão de visualizar o registro “1” e “3” e não o “2”, ou ainda que um grupo de usuário B possa editar os registros “5” e “7” mas não possa excluí-los.

21. IMPLANTAÇÃO E ATUALIZAÇÃO - Para manter os dados das tabelas do CAN íntegros entre o DN e os regionais e também prover um modo eficiente de implantar os sistemas no regional, foi criado um mecanismo de implantação e atualização de sistemas. Esse mecanismo funciona, de forma resumida, do seguinte modo: o desenvolvedor monta toda a estrutura da sua aplicação, com as operações, grupos de usuários, direitos de acesso, etc... e indica quem será o administrador do sistema no regional. Depois da estrutura montada, para uma administração, basta gerar a exportação para o regional desejado. - O resultado é um arquivo XML que contém todas as informações (referentes ao Controle de Acesso) necessárias à implantação do sistema na base do regional, bastando então enviar esse arquivo ao responsável que procederá a importação pela aplicação CAN.

22. IMPLANTAÇÃO E ATUALIZAÇÃO

23. IMPLANTAÇÃO E ATUALIZAÇÃO - Uma vez importado o arquivo de implantação o administrador do sistema local se torna o único responsável por definir os direitos de acesso. Essas exportações, realizadas aqui, e as importações, realizadas no regional, são todas guardadas formando um histórico que pode ser consultado através da aplicação CAN desktop.

24. IMPLANTAÇÃO E ATUALIZAÇÃO - O mesmo mecanismo é utilizado para quando há a necessidade de atualização das operações que o sistema suporta. Ou seja, não há mais a necessidade de rodar scripts para atualização de informações referentes ao controle de acesso. - O CAN foi projetado para que não haja nenhuma necessidade de se manipular o banco de dados diretamente no que se refere à implantação e atualização de sistemas nos regionais. A própria instalação do CAN utiliza o mecanismo descrito acima. A aplicação detectará que nunca fora instalada na base de dados e então solicitará o arquivo XML para proceder à implantação dos dados iniciais.

25. SEGURANÇA - Com certeza, com o novo controle de acesso e o mecanismo de chave de ativação de sistemas, estamos dando um importante passo de modo a dificultar bastante o acesso à informação sem a devida autorização. No entanto, não seremos eficazes se não adotarmos todas as medidas propostas ou se não tivermos profissionais à frente dos SGBD comprometidos com as políticas necessárias. - Com o CAN as responsabilidades na delegação dos direitos de acesso estão mais claramente definidas, pois fica perfeitamente compreendido até onde vai a responsabilidade do DN e começa a do regional. Podemos separar as medidas de segurança em 5 pontos principais: 1 – Conexão com o banco de dados 2 – Obtenção e distribuição de login 3 – Entrada no sistema 4 – Controle de sessão e inatividade do sistema 5 – Conscientização do usuário da confidencialidade da senha

26. SEGURANÇA - 1 - No primeiro item, a exigência era garantir uma maneira em que o administrador local fosse o responsável por definir as senhas de conexão com o banco de dados de modo a acabar com as senhas conhecidas por todos. Para isso, foi criado o mecanismo denominado “Ativador de Sistemas”, que na verdade encapsula um modo de distribuir a senha de conexão para cada sistema. Ou seja, o administrador local, quando ocorrer a implantação de um sistema que trabalha sobre o BDPROD, deverá criar no servidor o usuário respectivo ao novo sistema com senha de sua escolha. Após isso, bastará entrar no programa “Ativador de Sistemas” e gerar a chave de ativação que conterá a sigla do sistema e senha encriptadas, distribuindo-a então aos usuários.

27. SEGURANÇA - 1 AtivadorSistemaApp.exeGera-se a chave por esse programa

28. SEGURANÇA - 1 Entrada de sistema em máquina onde a chave não foi encontrada

29. SEGURANÇA - 1 Caso a conexão com o banco de dados não for estabelecida, o erro Será interceptado e a seguinte mensagem será exibida ao usuário: Mensagem para conexão com SGBD mal sucedida

30. SEGURANÇA - 1 - De modo a criarmos um procedimento padrão e disciplinarmos a adoção deste, cada sistema terá o seu próprio usuário de acesso ao SGBD, descontinuando o compartilhamento de um usuário por mais de um sistema. Dessa forma o administrador no regional detém o controle e consequentemente possui a responsabilidade sobre as contas de acesso ao banco de dados.

31. SEGURANÇA - 2 - O segundo item é o que se refere à obtenção e distribuição de login. Como já mencionamos, todo usuário será uma pessoa identificada no CNRH e somente os administradores poderão gerar a chave de autenticação necessária ao ingresso do usuário em qualquer base. Uma chave gerada para um regional não conseguirá ser utilizada em outro, neste caso em que o mesmo usuário precisa trabalhar em dois regionais diferentes deve-se explicitamente gerar outra chave para o regional desejado. No caso de aplicação web, que rodam sobre o BDPROD-DN, basta proceder a geração das chaves dos usuários que os mesmos serão criados na base. - Todo usuário começa com uma senha aleatória e expirada.

32. SEGURANÇA - 2

33. SEGURANÇA - 2 Arquivo recebido por download automático como resultado da geração de chaves que deverá ser importado na aplicação CAN(desktop).

34. SEGURANÇA - 3 - O terceiro item de segurança refere-se à entrada no sistema. No ato do login, algumas informações constantes na chave de autenticação do usuário são checadas para verificar a validade da mesma. Após isso, dado o regional e a UOP(se for o caso), informados pela aplicação, verifica-se em quais grupos de usuário o mesmo faz parte. Se houver algum grupo de usuário do sistema em questão que atenda as restrições de administração e UOP indicadas e que o usuário participe, ele é autorizado a entrar no sistema. - Outra questão verificada na entrada é se o usuário não tentou efetuar o logon no sistema várias vezes e errou a senha. Se o usuário errar mais de 5 vezes no intervalo de 1 minuto o seu acesso é bloqueado, cabendo ao pessoal de TI verificar o ocorrido e conforme for proceder o desbloqueio.

35. SEGURANÇA - 3

36. SEGURANÇA - 4 - O quarto ponto basicamente resume-se a dois mecanismos de controle que são: controle de sessão e de inatividade do sistema. O controle de sessão funciona da seguinte forma: ao efetuar o login, é criado um registro no banco de dados com um identificador único da sessão, Id do usuário, Id do sistema, data e hora de início e de término da sessão. A cada chamada feita ao controle de acesso a sessão é prolongada pelo tempo de sessão definido pelo administrador do sistema. Se no momento da chamada a sessão já estiver expirada, uma exceção é lançada e o usuário será obrigado a fazer logon novamente. - As sessões podem ser expiradas também propositalmente. Ao tirar um sistema do ar, todas sessões ativas são expiradas e a criação de novas sessões é impedida, emitindo ao usuário que tentar efetuar o logon a mensagem cadastrada pelo administrador do sistema.

37. SEGURANÇA - 4

38. SEGURANÇA - 4 - O outro mecanismo complementar, que funciona somente para aplicações desktop, é o “TimeOutController” que dispara um evento quando o sistema fica inativo. Ou seja, o desenvolvedor pode automaticamente efetuar logoff e chamar a tela de logon sempre que o sistema ficar inativo por um período de tempo que o administrador define através da aplicação CAN.

39. SEGURANÇA - 5 • Algoritmo para checar se a senha escolhida pelo usuário é insegura. Solução simples de modo a orientar o usuário na escolha da sua assinatura eletrônica, pois já que estamos garantindo a confidencialidade da sua senha e promovendo uma série de recursos de segurança, precisamos conscientizar os usuários na definição da sua assinatura. O mecanismo está, atualmente, implementado de forma a avisar o usuário esclarecendo-o, no entanto sem impedi-lo de definir uma senha fácil.

40. SEGURANÇA - 5 • Os seguintes pontos são analisados: • - Utilização de senha que tenha o login em seu conteúdo; • - Utilização dos nomes que constituem o nome completo como parte da senha; • - A senha precisa ter no mínimo 6 caracteres e é "case-sensitive"; • - Senha com menos de 3 caracteres diferentes; • - Seqüências do tipo "1234", "1111", "ABCD", "AAAA" e "ABABABAB" são detectadas; • - Senhas contendo palavras muito utilizadas no SESC: "TESTE", "SENHA", "SESC", "SOCIAL", "EDUCACAO", "ODONTO", "CAIXA", "LAZER", etc... • É importante difundir a cultura de que a senha nos sistemas corporativos é a assinatura digital do usuário e assim como no papel intransferível.

41. PRÓXIMAS IMPLEMENTAÇÕES - Solução de modo que um sistema possa ter vários administradores com direitos particionados por área de sistema. Exemplo: SGF com um administrador para a contabilidade e outro para a tesouraria, cada um deles sem poder delegar direitos que não os competem.

42. ACESSEM O SITE DO CAN EM http://intranet.sesc.com.br/can/ E-MAIL: can@sesc.com.br