Linha Logix

Páginas filhas
  • LGPD - Lei Geral de Proteção de Dados - Linha Logix

LGPD - Lei Geral de Proteção de Dados

Página centralizadora das informações com impactos no produto TOTVS (Linha Logix)


Informações Gerais sobre a LGPD

Conheça o objetivo, princípios, direitos e penalidades da Lei Geral de Proteção de Dados na página da Consultoria de Segmentos dedicada à LGPD.

Acesse: https://espacolegislacao.totvs.com/lgpd/

Adequações no produto para atender à LGPD

Funções e orientações para auxiliar o cliente a gerir a proteção de dados pessoais, considerando os principais requisitos previstos na LGPD:

  1. Configurações Dados Protegidos
  2. Auditoria dos Dados
  3. Segurança das Informações
  4. Consentimento
  5. Protocolos
  6. Integrações
  7. Criptografia
  8. Anonimização
  9. Relatório Dados do Titular
  10. Responsabilidades do Cliente
  11. Eventos webinar LGPD
  12. FAQs


1. Configurações Dados Protegidos

Consiste na configuração das tabelas e campos que contém dados pessoais/sensíveis ou que podem ser anonimizados.

Por meio da função "Gerenciamento de Campos Pessoais", é possível visualizar o mapeamento dos campos pessoais e sensíveis existentes no produto Logix e adequá-los de acordo com o entendimento da empresa.

Importante!

A TOTVS liberou o mapeamento mínimo e sugestivo de campos pessoais. É de responsabilidade do cliente, como controlador, revisar a configuração, acrescentando ou alterando dados, inclusive as classificações que foram liberadas pela TOTVS, conforme seu entendimento e orientação de sua área jurídica.

Além disso existe as configurações para realizar a integração com o Todos Privacidade de Dados (TPD), pois é essa ferramenta que o Logix utiliza para enviar as informações e entrar em conformidade dom a LGPD (Lei Geral de Proteção de Dados).

Configurador Logix




    CONTEÚDO

    1. Visão Geral
    2. Exemplo de utilização
    3. Tela LOG10000
      1. Principais Campos e Parâmetros
    4. Operações

    01. VISÃO GERAL

    Disponibilizar uma aplicação para que seja possível manter uma lista de campos do produto que tenham relação com informações consideradas pessoais e/ou sensíveis seja de usuários do produto ou até informações pessoais de qualquer pessoa que possam estar registradas em tabelas do produto Logix.

    A lista de campos protegidos é identificada por tabelas e colunas do Banco de Dados onde as informações são armazenadas e também faz referência ao nome dos programas do produto Logix que exibem e/ou atualizam tais informações. Desta forma facilita a identificação das telas do produto que fazem uso de dados sensíveis.

    O usuário responsável por manter a atualização destas informações cadastrais no produto é denominado Controlador.

    02. EXEMPLO DE UTILIZAÇÃO

    Com a utilização da aplicação LOG10000 (Dados Protegidos), o Controlador tem acesso a registrar as seguintes informações:

      1. Indicar se um determinado campo utilizado e exibido em telas do produto é considerada pessoal e/ou sensível;
      2. Indicar se o conteúdo de um determinado campo que é exibido em telas do produto pode ou não ser anonimizado;
      3. Classificar a informação conforme seu tipo de documento (CPF, RG, e-mail);
      4. Classificar a informação quanto ao tipo de tratamento;
      5. Informar os processos que utilizam o campo;

    03. TELA LOG10000





























    Principais Campos e Parâmetros

    Campo Descrição
    Tabela

    Nome da tabela do banco de dados utilizada pelo produto Logix, que faz referência a alguma coluna que possui informações sensíveis ou pessoais.

    (seleção) Esta tabela obrigatoriamente precisa estar registrada no cadastro de tabelas do metadados Logix (FRM1007).
    Coluna Nome da coluna relacionada a tabela de banco de dados que armazena alguma informação de usuário que seja considerada pessoal ou sensível.
    Proprietário Campo informativo (não editável) que representa se o campo foi registrado e é mantido pela TOTVS (Padrão) ou se foi registrado manualmente (Específico).
    Características

    Permite parametrizar a informação como Pessoal, Sensível e se deve ser anonimizada.

    Nota

    Quando a informação é registrada como Sensível, o sistema obrigatoriamente assume que é também uma informação Pessoal.
    Tipo de documento

    Classifica a informação quanto ao seu tipo / origem (CPF, RG ou e-mail)
    Classificações

    Classifica a informação quanto a forma que será tratada no sistema, conforme lista de classificações pré-determinada:

    • Execução de contrato;
    • Obrigação Legal;
    • Consentimento;
    • Execução de políticas públicas;
    • Estudo por órgão de pesquisa;
    • Exercício regular de direito;
    • Para a proteção da vida;
    • Para tutela de saúde;
    • Interesse legítimo;
    • Proteção de crédito;
    • Outros.

    É obrigatória a inclusão de pelo menos um classificador e para cada classificador deverá haver uma justificativa.
    Processos Lista dos processos (programas) do produto Logix que utilizam e exibem as informações da tabela e coluna do banco de dados informado.



    04. OPERAÇÕES


    Nome Função
    Situação Altera a situação do campo protegido. Mais detalhes aqui

    Exportar

    Realiza a exportação dos campos protegidos. Mais detalhes aqui

    Importar

    		 Realiza a importação dos campos protegidos. Mais detalhes aqui
    Auditoria Gera a auditoria dos campos protegidos. Mais detalhes aqui
    Sincronizar Sincroniza os registros com o TOTVS Privacidade de Dados. Mais detalhes aqui



    Situação

    Responsável por alterar a situação do campo, sendo que existem dois tipos de situação: Ativo e Inativo.

    • O campo inativo será ignorado nas solicitações de consulta e anonimização dos dados (TOTVS Privacidade de dados).
    • O campo inativo será ignorado na sincronização dos dados com o TPD (TOTVS Privacidade de dados).


    Exportar (LOG10001)

    Nesta tela existe o campo para definição do diretório da origem do arquivo que será exportado. O nome do arquivo é definido na geração do arquivo, não sendo possível informá-lo

    A funcionalidade consiste em exportar todas as informações relacionadas aos dados pessoais e sensíveis presente no banco de dados.

    A representação desta tela pode ser verificada na imagem abaixo:







    Aviso

    É importante se atentar para o NOME do arquivo, pois ele é definido na geração do arquivo e NÃO é possível informá-lo! O padrão do nome utilizado para criação do arquivo é "private_data.mzp".

    Importar (LOG10002)

    Nesta tela é apresentado o campo para seleção do arquivo que será importado, ele precisa existir previamente, sendo aceito apenas arquivos no formato *.mzp exportados pelo LOG10001 ou enviados pela TOTVS.

    Abaixo deste campo existe a opção para indicar se no processo de importação, serão eliminados os registros específicos que já estão presentes na base do cliente. 

    A representação desta tela pode ser verificada na imagem abaixo:


    Aviso

    É importante se atentar para o FORMATO do arquivo, pois somente serão aceitos no formato MZP exportados pelo LOG10001 ou enviados pela TOTVS.

    Atenção para as regras da importação:

    • Se a opção "Sobrescrever sugestões alteradas?" não estiver selecionada:
      • Os registros são inseridos ou atualizados de acordo com o arquivo;
      • Os registros que estão inativos, permanecem inalterados;
      • Caso o arquivo contenha um registro que no banco está Inativo, o mesmo não será 'reativado' e atualizado;
      • Os registros de processos são adicionados, caso não exista.
    • Se a opção "Sobrescrever sugestões alteradas?" estiver selecionada:
      • Os registros são inseridos ou atualizados de acordo com o arquivo;
      • As sugestões alteradas que se tornaram específicos, são sobrescritas (volta ao estado de sugestão inicial);
      • Os registros inativos, não são atualizados;
      • Caso o arquivo contenha um registro que no banco está Inativo, o mesmo não será 'reativado' e atualizado;
      • Os registros de processos são adicionados, caso não exista.


    Aviso

    Os registros gerados ou modificados pelo cliente nunca serão atualizados pelos arquivos enviados pela TOTVS. 

    Auditoria

    Responsável por criar auditoria para os campos ativos existentes no cadastro. Será criada uma auditoria para inclusão com o nome "TI_SGDP_TDP_[TABELA]", uma de exclusão com o nome "TD_SGDP_TDP_[TABELA]" e uma de atualização com o nome "TU_SGDP_TDP_[TABELA]". Assim que executada a opção as auditorias já passam a ficar ativas.

    Mensagem ao executar a opção:










    Para a primeira execução será criada auditoria para todos os campos, para as demais execuções será criado somente para os registros que sofreram alteração. Pois quando efetuada inativação de algum campo ou incluído novos campos esses registros ficam pendentes de criação de auditoria e somente eles serão processados.

    Toda a tabela incluída no LOG10000 deve possuir "Chave primária", pois com ela que será possível efetuar o rastreamento das informações, caso não possua é emitido mensagem abaixo  em tela, porém não bloqueia a inclusão. E no momento da criação da auditoria a mesma não será criada para tal tabela. Esta tabela ficará salva com erro de auditoria.









    Somente usuários administradores possuem permissão para executar esta opção.


    Sincronizar

    Responsável por sincronizar os dados existentes nos programas (LOG10003 e LOG10000) com o TOTVS Privacidade de Dados.

    Somente usuários administradores possuem permissão para executar esta opção.


    IMPORTANTE!

    Melhoria disponível no pacote oficial 12.1.27 ou Framework Fix 12.1.26.FIX02.




    O TOTVS Privacidade de Dados é uma ferramenta que complementa os recursos disponibilizados nas soluções TOTVS para apoiar seus clientes no atendimento das demandas dos titulares de dados pessoais, em conformidade com a LGPD (Lei Geral de Proteção de Dados).

    Configuração da Integração com TPD

      O que é?

      O TOTVS Privacidade de Dados é uma ferramenta que complementa os recursos disponibilizados nas soluções TOTVS para apoiar seus clientes no atendimento das demandas dos titulares de dados pessoais, em conformidade com a LGPD (Lei Geral de Proteção de Dados).

      Características

      • Aplicação web, desenvolvida no modelo SaaS (Software as a service). Não requer instalação local e o tempo da contratação à utilização é o menor possível.
      • Utiliza segurança de acesso integrada fornecida pelo TOTVS Identity.
      • Centraliza a gestão de solicitações de titulares de dados para pedidos de consulta de dados pessoais, anonimização desses dados, bem como a consulta de tratamentos realizados sobre eles.
      • Possibilita a interação entre o cliente TOTVS e o titular através de e-mails.
      • Consolida os resultados das solicitações, fornecendo uma resposta única a solicitação do titular dos dados pessoais.
      • Soluções TOTVS on-premises e SaaS podem ser integradas à ferramenta.

      Requisitos

      Para utilizar a ferramenta, é necessário atender os seguintes requisitos:

      • Ser cliente TOTVS e possuir uma das soluções integradas a ferramenta. Consulte a lista de soluções integradas aqui.
      • Ter realizado o mapeamento dos dados pessoais e dos processos que atuam sobre os mesmos na sua empresa.
      • Ter revisadas e ajustadas, quando se aplicar, as configurações de privacidade disponibilizadas nas soluções TOTVS contratadas.
      • Habilitar a ferramenta de trilha de auditoria das soluções TOTVS contratadas, quando disponível.
      • Ter um responsável (encarregado de dados) pela gestão dos dados pessoais na empresa (recomendado).

      Conteúdo



      01. Objetivo

      Esta documentação tem a finalidade de servir como uma guia no momento da integração do produto Logix com o TOTVS Privacidade de Dados (TPD). Para mais informações sobre a ferramenta, acesse TOTVS Privacidade de Dados.

      Para tanto, abaixo seguem as instruções para que a integração seja realizada corretamente.


      02. Informações

      O produto Logix faz uso de uma ferramenta chamada Smart Link, que é um mecanismo de troca de mensagens entre aplicações TOTVSApps e aplicações On Premises (ou remotas) onde:

      • Foi utilizada a biblioteca Smart Link Client Java, que por meio desta foi implementado o processador de troca de mensagens.
      • O processador de mensagens é uma aplicação java.

      Obtenha informações sobre os valores do client, secret, name e id do seu tenant de acesso do produto Logix no portal TPD para poder realizar as configurações necessárias para a integração com o Logix nos próximos passos. 

      Para mais detalhes leia Documentos de Referência do TOTVS Privacidade de Dados.


      03. Instalação Smart Link Client Java

      O arquivo smart-link-client.zip que, que contém a instalação/atualização da ferramenta SmartLink Client, é disponiblizado juntamente com o pacote de atualização do Logix na pasta LIBTOOLS/SMARTLINK.

      Extrair os arquivos em um diretório de sua escolha, sugerimos o uso do nome do seu tenant para complementar e facilitar a organização dos artefatos. 

      Exemplo:

      • O nome do tenant para exemplo é totvs-fwk e o nome da pasta extraída é smart-link-client.
        • "C:/TOTVS/totvs-fwk/smart-link-client"
      • Como resultado temos a estrutura abaixo:
        1. C:/TOTVS/totvs-fwk/smart-link-client/README.txt
        2. C:/TOTVS/totvs-fwk/smart-link-client/client/application.yml
        3. C:/TOTVS/totvs-fwk/smart-link-client/client/smart-link-client.jar
        4. C:/TOTVS/totvs-fwk/smart-link-client/client/log
        5. C:/TOTVS/totvs-fwk/smart-link-client/service/Windows/install.bat
        6. C:/TOTVS/totvs-fwk/smart-link-client/service/Windows/JavaService.exe
        7. C:/TOTVS/totvs-fwk/smart-link-client/service/Windows/uninstall.bat
        8. C:/TOTVS/totvs-fwk/smart-link-client/service/Linux/install.sh
        9. C:/TOTVS/totvs-fwk/smart-link-client/service/Linux/SmartLinkClient.service
        10. C:/TOTVS/totvs-fwk/smart-link-client/service/Linux/SmartLinkClient.sh
        11. C:/TOTVS/totvs-fwk/smart-link-client/service/Linux/start.sh
        12. C:/TOTVS/totvs-fwk/smart-link-client/service/Linux/stop.sh
        13. C:/TOTVS/totvs-fwk/smart-link-client/service/Linux/uninstall.sh



      Editar o arquivo "/service/Windows/install.bat"

      :default
@echo on

chcp 65001

set LINK_CLIENT=C:/TOTVS/smart-link-client/client

JavaService.exe -install "TOTVS-SMART-LINK-CLIENT" "%JAVA_HOME%/bin/server/jvm.dll" -Djava.class.path="%LINK_CLIENT%/smart-link-client.jar" -start org.springframework.boot.loader.JarLauncher -err "%LINK_CLIENT%/log/smart-link-client_err.log" -current "%LINK_CLIENT%" -manual -description "TOTVS LOGIX SMART LINK CLIENT"

@echo off

:eof

@echo .
@echo .
@echo .
PAUSE.


      Nome do serviço

      • Por padrão temos o nome do serviço definido como "TOTVS-SMART-LINK-CLIENT"
      • Sugerimos o uso do nome do seu tenant para complementar e facilitar a organização do serviço.


      Descrição do serviço

      • A descrição do serviço pode ser alterada por meio do parâmetro -description.

      JAVA

      • Deve ser utilizado JAVA 11
      • No arquivo estamos utilizando o %JAVA_HOME% como padrão, caso necessário faça a alteração para utilizar a sua variável de ambiente já existente.

      Parâmetros

      • Os parâmetros -Djava.class.path, -current e -err fazem o uso do valor informando em LINK_CLIENT (ajustar para o diretório definido nas etapas anteriores).

      Instalação do serviço:

      • Executar Prompt de Comando do sistema operacional como administrador.
      • Executar o arquivo de lote /service/Windows/install.bat.

      Editar o arquivo "/service/Windows/uninstall.bat"

      • Informe o nome do serviço definido na etapa anterior (Instalador de serviço para Windows)

      Desinstalação do serviço:

      • Execute Prompt de Comando como administrador
      • Execute o arquivo "/service/Windows/uninstall.bat"

      Para a instalação do serviço no Linux certifique-se de que os passos a seguir foram realizados:

      1. Definir a descrição do serviço:
        1. Edite o arquivo service/Linux/SmartLinkClient.service, localizado no local onde o projeto foi extraído, e informe no atributo "Description", a descrição do serviço:
        2. Por padrão temos o nome do serviço definido como "TOTVS-SMART-LINK-CLIENT"
        3. Sugerimos o uso do nome do seu tenant para complementar e facilitar a organização do serviço.
      2. Configurar o arquivo application.yml
        1. Veja a sessão 04. Configuração deste documento.
      3. Editar o arquivo "/service/Linux/install.sh" localizado onde o projeto foi extraído.
        1. Informar na variável PATH_SOURCE_SMART_LINK_CLIENT, localizado na linha 13, o local onde o projeto foi extraído.


      #!/bin/bash

ERRO="A instalação do Smart Link Client encontrou problema(s). Verifique o(s) aviso(s) acima."

checkCommandError(){
        if [ $? -ne 0 ]; then
		echo ""
		echo "$ERRO"
		exit 0
        fi
}

PATH_SOURCE_SMART_LINK_CLIENT="local-onde-foi-extraido/smart-link-client"
PATH_SMART_LINK_CLIENT="/usr/local/smart-link-client"

checkCommandError

echo "Instalação do Smart Link Client"

echo 'Copiando SmartLinkClient.service para /etc/systemd/system'
sudo cp -p "$PATH_SOURCE_SMART_LINK_CLIENT/service/Linux/SmartLinkClient.service" /etc/systemd/system/SmartLinkClient.service
checkCommandError

echo 'Copiando SmartLinkClient.sh para /usr/local/bin' 
sudo cp -p "$PATH_SOURCE_SMART_LINK_CLIENT/service/Linux/SmartLinkClient.sh" /usr/local/bin/SmartLinkClient.sh
checkCommandError

echo 'Concedendo permissao para execucao'
sudo chmod +x /usr/local/bin/SmartLinkClient.sh
checkCommandError

sudo mkdir "$PATH_SMART_LINK_CLIENT"
checkCommandError

sudo mkdir "$PATH_SMART_LINK_CLIENT/client"
checkCommandError

echo "Copiando $PATH_SOURCE_SMART_LINK_CLIENT/client para $PATH_SMART_LINK_CLIENT" 
sudo cp -r "$PATH_SOURCE_SMART_LINK_CLIENT/client/" "$PATH_SMART_LINK_CLIENT"
checkCommandError

sudo mkdir "$PATH_SMART_LINK_CLIENT/service"
checkCommandError

echo "Copiando $PATH_SOURCE_SMART_LINK_CLIENT/service/Linux/start.sh para $PATH_SMART_LINK_CLIENT/service" 
sudo cp -r "$PATH_SOURCE_SMART_LINK_CLIENT/service/Linux/start.sh" "$PATH_SMART_LINK_CLIENT/service"
checkCommandError

echo "Copiando $PATH_SOURCE_SMART_LINK_CLIENT/service/Linux/stop.sh para $PATH_SMART_LINK_CLIENT/service"
sudo cp -r "$PATH_SOURCE_SMART_LINK_CLIENT/service/Linux/stop.sh" "$PATH_SMART_LINK_CLIENT/service"
checkCommandError

echo 'Habilitando SmartLinkClient ...'
sudo systemctl enable SmartLinkClient
sudo systemctl daemon-reload

echo 'Iniciando SmartLinkClient ...'
sudo systemctl start SmartLinkClient
echo 'Fim da instalacao.'


      Instalando o serviço:

      • Abra um terminal e execute o arquivo "/service/Linux/install.sh", que está localizado onde o projeto foi extraído.

      • O comando ficaria como:  sudo bash /<local-onde-projeto-foi-extraído>/smart-link-client/service/Linux/install.sh
      • O script de instalação fará a inicialização do serviço automaticamente.
      • Start e Stop manuais:
        • Caso necessite interromper ou inicial o serviço manualmente. 
        • Para iniciar o serviço, execute:   sudo bash /usr/local/smart-link-client/service/start.sh
        • Para parar o serviço, execute:   sudo bash /usr/local/smart-link-client/service/stop.sh


      Atenção

      O diretório no qual o projeto foi extraído não é o mesmo local onde o projeto será instalado:

      • A instalação do smart-link-client será em /usr/local/.
      • Após a instalação, o projeto extraído torna-se necessário somente para a execução do script de instalação e desinstalação, uma vez que os demais arquivos foram copiados para o destino /usr/local/smart-link-client.
      • A saída de logs do smart-link-client ocorrerá no diretório em que foi instalado, no caso, /usr/local/smart-link-client/client/log.


      • Abra uma sessão terminal e execute o arquivo /service/Linux/uninstall.sh, que está localizadon onde o projeto foi extraído.|
      • O comando ficaria como:   sudo bash /<local-onde-projeto-foi-extraido>/smart-link-client/service/Linux/uninstall.sh.
      • Ao desinstalar o serviço, a pasta /usr/local/smart-link-client será removida.


      04. Configuração Smart Link Client Java

      O arquivo de configuração é application.yml.

      Utilizando a pasta de exemplo dos passos anteriores, podemos encontrar o arquivo em /client/application.yml.

      Leia com atenção o detalhamento das configurações abaixo:


      # SERVER

      A porta de acesso da aplicação pode ser alterada na propriedade:

      # -------------------------------------------------
# SERVER
# -------------------------------------------------  
server:
  port: 8777

      https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.server.server.port


      # SPRING

      Por padrão estamos utilizando 10MB para poder trafegar metadado no formato JSON.

      # -------------------------------------------------
# SPRING
# ------------------------------------------------- 
spring:
  codec:
    max-in-memory-size: 10MB

      https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.core.spring.codec.max-in-memory-size


      # LOG

      O nome do arquivo de log pode ser alterado na propriedade name abaixo:

      # -------------------------------------------------
# LOG
# -------------------------------------------------    
logging:
  file:
    name: log/smart-link-client.log

      https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.core.logging.file.name


      # SMART LINK CLIENT


      # -------------------------------------------------
# SMART LINK CLIENT
# -------------------------------------------------
totvs:
  link:
    auth:
      url: INFORMAR_URL_RAC
      client: INFORMAR-CLIENT
      secret: INFORMAR-SECRET
    client:
      subscriptions:      
        - SGDPDataCommand
        - SGDPMaskCommand
		- SGDPLogsCommand
    server:
      host: INFORMAR_HOST
      port: 443
      secure: true
  tenant:
    name: INFORMAR-NOME-TENANT
    id: INFORMAR-ID-TENANT   
  product:
    name: 'Logix'
    url: 'INFORMAR_URL_LOGIX'
    username: 'INFORMAR_USUÁRIO'
    password: 'INFORMAR_SENHA'

      Leia com atenção o detalhamento das configurações abaixo:

      O Smart Link Client Java é uma biblioteca que facilita o desenvolvimento de um LINK Client para a plataforma Java, sendo necessária a implementação de uma aplicação que implemente um processador de mensagens (LINK Client Java Application mais abaixo).

      No Smart Link Client Java utiliza o protocolo GRPC, sendo necessária a seguinte configuração:

      totvs:
  link:
    server:
      host: INFORMAR_HOST
      port: 443
      secure: true
      • INFORMAR_HOST:  Utilizar o host conforme o tipo do seu ambiente:
        • DEV: api-smartlink.dev.totvs.app
        • STAGING: api-smartlink.staging.totvs.app
        • PROD: api-smartlink.totvs.app

      Deve ser informada também uma lista de subscrições, onde somente mensagens com determinados types são efetivamente enviadas para o Smart Link Client. 

      No Smart Link Client Java é necessária a seguinte configuração:

      totvs:
  link:
    client:
      subscriptions:
        - SGDPDataCommand
        - SGDPMaskCommand
	 	- SGDPLogsCommand

      O produto está preparado para processar os tipos SGDPDataCommand, SGDPMaskCommand e SGDPLogsCommand.

      O produto Logix suporta apenas o single tenant, sendo necessária a seguinte configuração:

      totvs:
  link:
    auth:
      url: INFORMAR_URL_RAC
      client: INFORMAR-CLIENT
      secret: INFORMAR-SECRET
      • INFORMAR_URL_RAC:  Utilizar a url conforme o tipo do seu ambiente, onde:

      DEV          https://admin.rac.dev.totvs.app/totvs.rac/connect/token

      STAGING  https://admin.rac.staging.totvs.app/totvs.rac/connect/token

      PROD        https://admin.rac.totvs.app/totvs.rac/connect/token

      • INFORMAR-CLIENT: Substituir pelo valor do seu client.
      • INFORMAR-SECRET:  Substituir pelo valor da sua secret.

      Informar os valores do seu Tenant:

      totvs:
  tenant:
    name: INFORMAR-NOME-TENANT
    id: INFORMAR-ID-TENANT
      • INFORMAR-NOME-TENANT: Substituir pelo nome do seu tenant.
      • INFORMAR-ID-TENANT:  Substituir pelo valor do ID do seu tenant.

      Utilize aspas simples para valores do tipo texto ao informar as configurações do produto.


      A  comunicação acontece nos dois sentidos (TOTVS Privacidade de Dados >> Logix) e (Logix >> TOTVS Privacidade de Dados) por meio das configurações abaixo:

      totvs:
  product:
    name: 'Logix'
    url: 'INFORMAR_URL_LOGIX'
    username: 'INFORMAR_USUÁRIO'
    password: 'INFORMAR_SENHA'
      • INFORMAR_URL_LOGIX: Substituir pelo valor do seu ambiente. Exemplo: http://localhost:8080
      • INFORMAR_USUÁRIO:  Substituir pelo valor de um usuário existente no produto. 
      • INFORMAR_SENHA:  Substituir pelo valor da senha do usuário.


      CONFIGURAÇÕES OBRIGATÓRIAS


      • Adicionar a configuração tpdDisabled para desativar a comunicação do entre o Smart Link Client e o Produto Logix.
      totvs:
  product:
    tpdDisabled: true


      • Caso necessário, adicionar a configuração linkClientUrl para indicar onde está o LINK Client Java Application.

      A configuração recebe o valor http://SERVIDOR:PORTA, onde:

      SERVIDOR:  Servidor que está executando o processador de mensagens smart-link-client.jar

      PORTA: Valor da porta (server: port) da configuração #SERVER

      Observação: Caso precise adicionar um valor diferente do padrão, você deverá adicionar a configuração:

      totvs:
  product:
    linkClientUrl: 'INFORMAR_URL_SMART_LINK_CLIENT'

      Ao informar o endereço de um ambiente com protocolo HTTPS na configuração totvs.product.url, realize a importação dos certificados do ambiente Logix na JVM que está executando o smart-link-client.jar, para importação utilize a ferramenta keytool.

      totvs:
  product:
    url: 'https://meu-servidor:8080'

      Ao atualizar qualquer propriedade de configuração o serviço deverá ser iniciado novamente, permitindo a leitura das configurações atualizadas.


      05. Inicialização do serviço instalado

      Após concluir as etapas anteriores, basta iniciar o serviço instalado e verificar no log se a aplicação foi iniciada com sucesso.


      Starting Application

      INFO 15788 --- [main] com.totvs.link.client.Application        : Starting Application v12.1.34-NFRW-SNAPSHOT on 00000 with PID 15788 (C:\TOTVS\smart-link-client\client\smart-link-client.jar started by 00000$ in C:\TOTVS\smart-link-client\client)
INFO 15788 --- [main] com.totvs.link.client.Application        : No active profile set, falling back to default profiles: default
INFO 15788 --- [main] com.totvs.link.client.LinkService        : *** Connecting to server (link.staging.totvs.app:443)
INFO 15788 --- [main] o.s.s.c.ThreadPoolTaskScheduler          : Initializing ExecutorService 'taskScheduler'
INFO 15788 --- [main] o.s.b.web.embedded.netty.NettyWebServer  : Netty started on port(s): 8777
INFO 15788 --- [main] com.totvs.link.client.Application        : Started Application in 4.994 seconds


      Para facilitar a visualização de log foi adicionada a infomação [SMART-LINK-CLIENT] no LOG para as classes java implementadas.

      INFO 3528 --- [main] c.totvs.link.client.ApplicationStartup   : [SMART-LINK-CLIENT][ApplicationStartup.readyEvent]
INFO 3528 --- [main] c.t.l.c.d.ProductSyncDefaultMetadata     : [SMART-LINK-CLIENT][ProductSyncDefaultMetadata.sync]
INFO 3528 --- [main] c.t.l.client.product.ProductSendMessage  : [SMART-LINK-CLIENT][ProductSendMessage.send][REQUEST][GET] to http://----:8380/api/sec/v1/sgdp/metadata/default
INFO 3528 --- [main] c.t.l.client.product.ProductSendMessage  : [SMART-LINK-CLIENT][ProductSendMessage.send][RESPONSE][GET][200] from http://----:8380/api/sec/v1/sgdp/metadata/default
INFO 3528 --- [main] c.t.l.c.d.ProductSyncDefaultMetadata     : [SMART-LINK-CLIENT][ProductSyncDefaultMetadata.sync] Sending message to Smart Link Server - type: SGDPUpdateApplicationMetadata - metadado: {"header":{"type":"SGDPUpdateApplicationMetadata"},"content":{"models":{},"codes":{},"package":"Logix","productId":"Logix","readOnly":true,"smartLink":"singleTenant","localLogs":false,"applicationId":"Logix"}}
INFO 3528 --- [main] c.t.l.c.d.ProductSyncDefaultMetadata     : [SMART-LINK-CLIENT][ProductSyncDefaultMetadata.sync] Sent to Smart Link Server

        ↑ início

      2. Auditoria dos Dados

      Consiste no monitoramento de ações (consulta, inclusão, alteração e exclusão) efetuadas com os campos pessoais e sensíveis mapeados.

      No produto TOTVS (Linha Logix), a auditoria é efetuada por meio das funções:

      • Log Execução Programas: permite auditar toda consulta realizada em programas que contenham campos pessoais e/ou sensíveis mapeados na função "Relacionamento das Rotinas com Campos Pessoais e/ou Sensíveis".
      • Audit Trail: permite auditar toda inclusão, alteração e exclusão de campos pessoais e/ou sensíveis mapeados na função "Gerenciamento dos Campos Pessoais e/ou Sensíveis".

      Para realizar esse gerenciamento existe o programa Cadastro Dados Protegidos - LGPD (LOG10000)

      Impacto no produto


        LOG10000 - Configurador de dados pessoais e sensíveis

        Auditoria

        Responsável por criar auditoria para os campos ativos existentes no cadastro. Será criada uma auditoria para inclusão com o nome "TI_SGDP_TDP_[TABELA]", uma de exclusão com o nome "TD_SGDP_TDP_[TABELA]" e uma de atualização com o nome "TU_SGDP_TDP_[TABELA]". Assim que executada a opção as auditorias já passam a ficar ativas.

        Mensagem ao executar a opção:










        Para a primeira execução será criada auditoria para todos os campos, para as demais execuções será criado somente para os registros que sofreram alteração. Pois quando efetuada inativação de algum campo ou incluído novos campos esses registros ficam pendentes de criação de auditoria e somente eles serão processados.

        Toda a tabela incluída no LOG10000 deve possuir "Chave primária", pois com ela que será possível efetuar o rastreamento das informações, caso não possua é emitido mensagem abaixo  em tela, porém não bloqueia a inclusão. E no momento da criação da auditoria a mesma não será criada para tal tabela. Esta tabela ficará salva com erro de auditoria.









        Somente usuários administradores possuem permissão para executar esta opção.


          ↑ início

        3. Segurança das Informações

        Consiste na configuração da segurança de acesso às informações pessoais e sensíveis.

        É responsabilidade do cliente, como controlador, proteger a camada de banco e sua infraestrutura, de forma a atender aos requisitos de segurança, aos padrões de boas práticas e de governança e aos princípios gerais previstos nesta Lei e às demais normas regulamentares.

        No produto TOTVS (Linha Logix) a segurança aos dados pessoais e sensíveis é por programa e usuários, sendo necessário validar o cadastro de usuários, grupos de usuários e as permissões existentes para acesso ao produto, assim como ao menu e estabelecimentos, restringindo o acesso à rotinas que apresentam dados pessoais e sensíveis, mantendo a segurança dos dados.

        A segurança de dados sensíveis pode ser feita por meio da utilização de perfis de segurança e caberá ao “controlador” definir quais profissionais da empresa podem ter acesso à informação.

        Impacto no produto




          CONTEÚDO

          01. VISÃO GERAL

          Neste programa é possível efetuar o cadastro e manutenção de usuários com acesso para uso do produto Logix.


          02. EXEMPLO DE UTILIZAÇÃO

          Entendendo o comportamento dos tipos de autenticação do Logix, foi provisionado um novo modo de configurar a autenticação do produto, agora, para nível de usuário. Ou seja:

          Cada usuário Logix poderá ter definida a forma como se dará a sua autenticação no sistema. Sendo assim, a configuração de autenticação realizada no programa LOG05050/LOG02700, permite que o modo como o usuário irá realizar a autenticação de seu login no sistema seja configurado para um ou mais usuários de forma diferenciada, sobrescrevendo o que foi previamente configurado no TOTVSPROFILE.pro. 

          Para efetuar a configuração do tipo de login por usuário, pode-se registrar a informação na área Tipo de Autenticação.

          03. TELA USUÁRIOS - Dados principais


          Outras Ações / Ações relacionadas

          Ação Descrição
          Barra de Ferramentas (Principais)
          Relatório Gera o relatório com os dados principais do usuário.
          Redefinir senha

          Realiza  a  modificação da senha do usuário.

          Nota:

          É necessário realizar a confirmação de senha do usuário conectado no produto.
          Sincronizar Realiza a sincronização de dados com o Fluig Identity.
          Docs. Associados

          Acessa a área de integração com o ECM.

          Nota:

          É necessário realizar a configuração das chaves no arquivo de configuração Profile.pro.
          Usuário
          Usuário  Código do usuário cadastrado no produto
          Nome Nome do usuário cadastrado no produto
          Configuração de contatos
          Telefone/Ramal Telefone do usuário e a Ramal (Caso exista).
          Fax Número para envio de FAX.

          Usuário/Grupo - URA

          Usuário utilizado para acesso à Unidade de Resposta Audível e seu grupo.

          Obs: Também existe a opção de permitir que o usuário possa utilizar a central telefônica
          E-mail E-mail do usuário com a opção de poder testar o envio de e-mail.
          Configuração Logix
          Tipo de autenticação

          • Padrão do Sistema: (Valor 0 no profile). Quando este valor for selecionado o tipo de autenticação adotado para o usuário será o que estiver configurado na chave de profile (chave logix.login.singleSignOn).

          • Login interno Logix: (Valor 1 no profile ou quando a chave logix.login.singleSignOn não estiver informada no arquivo de profile). Realizará o login pelo usuário e senha interno do Logix.

          • Login de rede (AD) - Não permite Logoff: (Valor 2 no profile). Este modelo não permitirá logoff do usuário, onde, somente usuários de rede que devidamente estão registrados no Logix poderão autenticar-se. Para isso precisa registrar os campos Usuário de rede e Domínio de rede no cadastro de usuário para os respectivos usuários da rede de domínio X usuário Logix. Após conectado ao sistema, não será permitida troca de usuários, apenas troca de empresas, respeitando a lista de empresas para as quais tiver permissão de acesso no sistema.

          • Login de rede (AD) - Permite Logoff: (Valor 3 no profile). Somente permitirá acesso dos usuários devidamente registrados no Logix. Para isso precisa registrar os campos Usuário de rede e Domínio de rede no cadastro de usuário para os respectivos usuários da rede de domínio X usuário Logix. Após conectado ao sistema, será permitida troca de usuários ou troca de empresas, respeitando a lista de empresas para as quais tiver permissão de acesso no sistema.

          • Login via Provedor de Identidade - Permite Logoff. (Valor 5 no profile). Somente permitirá acesso dos usuários devidamente registrados no Logix onde o campo de E-mail no Cadastro de Usuários estiver com o mesmo e-mail de usuário registrado no provedor de identidade utilizado para autenticação. Após conectado ao sistema, será permitida troca de usuários fazendo nova autenticação, ou troca de empresas respeitando a lista de empresas para as quais o usuário tiver permissão de acesso no sistema.  ESTA OPÇÃO ESTÁ DISPONÍVEL A PARTIR DO LOGIX 12.1.2309 OU LOGIX FRAMEWORK 12.1.2305.FIX01
          Empresa padrão

          Código da empresa padrão do usuário que será utilizado para parametrização de relatórios e parâmetros gerais do Logix.

          Obs: Na tela de login é possível mudar a empresa antes o usuário realizar o login no produto.
          É administrador? É possível definir se o usuário será Administrador do produto.
          Permite acesso à Pesquisa Relacional?

          Também é possível estabelecer se terá acesso à Pesquisa relacional.

          A pesquisa relacional é uma ferramenta que permite ao usuário criar suas próprias visões por meio de uma interface intuitiva e sem a necessidade de programação. O usuário cria os seus modelos de pesquisa e pode salvá-lo em sua área de trabalho. A pesquisa relacional é baseada nos relacionamentos das tabelas Logix, permitindo que as informações sejam apresentadas em múltiplas janelas ou em uma única janela de forma dinâmica, por meio de relacionamentos pré-estabelecidos.

          IMPORTANTE!

          Além da permissão para Pesquisa Relacional ser realizada no cadastro de Usuários (Log2700), é necessário ativar as permissão de Acesso às Tabelas (Log5510) nas tabelas de Administração Logix no programa Log5510 (acesso também pelo Log05050).
          Data de inclusão Data em que o usuário foi cadastrado no sistema.
          Dispositivo padrão Código do dispositivo de saída padrão do usuário. 
          Autenticação externa (Active Directory)
          Usuário de rede Login de domínio de rede do usuário.
          Domínio de rede Domínio de rede utilizado pelo usuário.

          04. TELA ENVIO DE E-MAIL LOGIX



          Principais Campos e Parâmetros

          Campo Descrição
          Básico

          Para - Endereço de e-mail do destinatário que receberá a mensagem.

          CC -  Endereço de e-mail do destinatário que receberá a mensagem em cópia.

          CCO - Endereço de e-mail do destinatário que receberá a mensagem em cópia oculta.

          Assunto - Título do e-mail

          Anexos - Possibilidade de colocar arquivos em anexo para o envio.

          Mensagem -  Corpo da mensagem. Conteúdo do que será enviado no e-mail, que pode ser formatado conforme as opções da tela.
          Avançado

          Responder para - Endereço que receberá as respostas do e-mail enviado. 

          Obs: É possível marcar a opção para Solicitar confirmação de leitura.

          Servidor - Endereço do serviço de hospedagem de e-mail utilizado. 

          Porta - Número da porta de conexão  com o servidor SMTP para o envio de e-mail.

          Nota:

          Se esta configuração não for informada, por padrão, será utilizada a porta 25 ou 587 caso haja um protocolo de segurança.


          Caso tenha Autenticação SMTP:

          Usuário SMTP - Usuário de autenticação com o servidor SMTP para o envio de e-mail, esta configuração não é obrigatória caso o servidor não possua autenticação.

          Senha do usuário SMTP - Senha do usuário de autenticação com o servidor SMTP para o envio de e-mail, esta configuração não é obrigatória caso o servidor não possua autenticação.

          TimeOut (segundos) - Tempo máximo, em segundos, de tentativa de conexão com o servidor de e-mail.

          Nota

          Se esta configuração não for informada, será utilizada por padrão o tempo máximo de 30 segundos.

          Protocolo de segurança - Protocolo de segurança utilizado pelo servidor de e-mail, sendo TLS ou SSL. 

          Notas

          • Esta configuração não é obrigatória quando o servidor não utiliza um protocolo de segurança.
              • Nenhum;
              • TLS;
              • SSL.

          Remetente padrão - Endereço de e-mail único para todos os e-mail enviados pelo Logix.

          Nota

           Esta configuração não é obrigatória.


          05. TELA USUÁRIOS - Dados complementares


          Principais Campos e Parâmetros

          Campo Descrição
          Limite de processos por conexão  Quantidade máxima de processos que o usuário poderá possuir no Logix. Caso o valor esteja em branco ou nulo, não haverá limite para a quantidade de processos.
          Limite de conexões

          Quantidade de sessões que o usuário poderá ter em execução simultaneamente.
          Diálogo de configuração de impressão

          Indica a forma que será exibido o diálogo de configuração de impressão.

            • Sempre exibir;
            • Solicita confirmação do usuário;
            • Respeita configuração padrão.
          Próxima sequência de relatório

          Valor sequencial a ser gerado pelo Logix, caso o usuário esteja utilizando o controle de numeração.


          06. TELA USUÁRIOS - Parâmetros de acesso

          Principais Campos e Parâmetros

          Campo Descrição

          Expiração senha (em meses)

          Quantidade de meses contatos a partir da data da inclusão que será o prazo para expirar a senha.

          Limite de tentativas de login

          Quantidade de tentativas permitidas para acessar o sistema.

          Exemplo: caso seja informado 3, e se o usuário errar 3 vezes a senha, o usuário será bloqueado.

          Quantidade Máxima de Usuários Ativos

          Quantidade máxima de logins ativos que o usuário poderá possuir no Logix.

          Bloqueio de login (em segundos)

          Quantidade em segundos que o login ficará bloqueado.

          Hora inicial de acesso

          Hora inicial em que o usuário acessou o sistema.
          Hora final de acesso Hora final em que o usuário saiu do sistema.

          Auditoria de execuções de programas

          Indica qual forma será efetuada a auditoria para execução de programas.

            • Todos;
            • Apenas o último acesso;
            • Nenhum



          07. TELA USUÁRIOS - Bloqueios


          Principais Campos e Parâmetros

          Campo Descrição

          Usuário bloqueado?

          Identifica se um usuário Logix está bloqueado para uso do sistema.

          Na tela ainda é possível verificar algumas informações sobre o Bloqueio:

          • Motivo: Código do motivo do bloqueio;
          • Descrição: Descrição do motivo do bloqueio;
          • Início do bloqueio: Data em que começa o bloqueio do usuário;
          • Fim do bloqueio: Data em que termina o bloqueio do usuário;
          • Data do bloqueio: Data em que o usuário foi bloqueado;
          • Usuário bloqueio:  Código do usuário que realizou o bloqueio;
          • Nome: Nome do usuário que bloqueou;


          OBS:

          Para realizar a manutenção do bloqueio (Bloquear/Desbloquear, Cadastrar Motivo, etc) acessar o programa Administração Logix (Log05050)



          IMPORTANTE!

          Para mais funcionalidades referente ao usuário, acessar o programa Administração Logix - LOG05050


          Conteúdos Relacionados




          CONTEÚDO

          01. VISÃO GERAL

          Este programa promove a manutenção dos grupos de usuários do produto Logix.

          O programa Log02710 é acessado pelo cockpit do programa de Administração Logix - Log05050.


          02. EXEMPLO DE UTILIZAÇÃO

          No programa Log02710 é possível criar e modificar Grupos para os usuários.

          Porém para excluir algum grupo, é necessário realizar uma pesquisa, para listar os grupos existentes ou o específico, em seguida clicar com o botão direto do mouse e, então excluir a linha do registro.


          03. TELA GRUPOS

          Outras Ações / Ações relacionadas

          Ação Descrição

          Grupo

          Nome do grupo.

          Descrição

          Descrição do grupo.

          Uso do coletor

          Indica se o grupo terá acesso via MEN3000 para uso de coletor de dados.









          CONTEÚDO

          01. VISÃO GERAL

          Este programa promove a manutenção dos grupos de um usuário em específico do produto Logix.

          O programa Log02720 é acessado pelo cockpit do programa de Administração Logix - Log05050.


          02. EXEMPLO DE UTILIZAÇÃO

          No programa Log02720 é possível incluir, modificar e excluir os Grupos de um usuário.

          Porém para excluir algum grupo em específico do usuário, é necessário acessar a Grid em modo de edição (Botão modificar), em seguida clicar com o botão direto do mouse e, então excluir a linha do registro.

          Ao utilizar as setas de deslocamento é possível navegar entre os usuários e visualizar seus grupos


          03. TELA  GRUPOS DO USUÁRIO

          Outras Ações / Ações relacionadas

          Ação Descrição

          Usuário

          Código e nome do usuário que possui grupos onde faz parte.
          Grupo Código do grupo associado ao usuário.

          Descrição do grupo

          Descrição do grupo associado ao usuário.









          CONTEÚDO

          01. VISÃO GERAL

          Este programa promove a manutenção dos usuários de um grupo em específico do produto Logix.

          O programa Log00077 é acessado pelo cockpit do programa de Administração Logix - Log05050.


          02. EXEMPLO DE UTILIZAÇÃO

          No programa Log00077 é possível incluir, modificar e excluir os usuários de um Grupos.

          Porém para excluir algum usuário em específico do grupo, é necessário acessar a Grid em modo de edição (Botão modificar), em seguida clicar com o botão direto do mouse e, então excluir a linha do registro.

          Ao utilizar as setas de deslocamento é possível navegar entre os usuários e visualizar seus grupos.


          03. TELA  USUÁRIO DO GRUPOS

          Outras Ações / Ações relacionadas

          Ação Descrição

          Grupo 

          Código e nome do grupo que possui usuários associados.
          Usuário Código do usuário associado ao grupo.

          Descrição do usuário

          Descrição do usuário associado ao grupo.









          CONTEÚDO

          01. VISÃO GERAL

          Este programa promove a manutenção de acesso por usuários aos processos Logix.

          O programa Log5500 é acessado pelo cockpit do programa de Administração Logix - Log05050.


          02. EXEMPLO DE UTILIZAÇÃO

          Ao acessar o programa Administração Logix - Log05050 e realizar uma pesquisa, será solicitado para escolher quem será a permissão, que pode ser para um Usuário ou um Grupo de usuários:

           

          03. TELA PERMISSÃO DE ACESSO

          Outras Ações / Ações relacionadas

          Ação Descrição

          Usuário/grupo

          Código do usuário ou grupo.

          Empresa

          Código da empresa.

          Opção

          Indica se libera ou bloqueia os programas para o usuário/grupo:

            • Liberar tudo;
            • Bloquear tudo.

          Ir para o processo

          Procura automaticamente a localização do programa na árvore do menu.
          Menu Logix

          Árvore de processos Logix. Nesta árvore encontram-se todos os processos cadastrados no menu Logix.

          Para alterar as permissões, deve-se prosseguir da seguinte forma:

                 Clicar com o botão direito do mouse sobre o item no qual deseja alterar a permissão.

                 As opções disponíveis para alteração de permissão são:

            • Liberar acesso: clique para liberar acesso total para a área/sistema/níveis/processos;
            • Bloquear acesso: clique para bloquear acesso total para a área/sistema/níveis/processos;
            • Opções de acesso: clique para exibir e permitir liberar ou bloquear determinadas funcionalidades do programa e seus respectivos campos.

          Opções de acesso

          Aba: Barra de ferramentas

          Exibe as funcionalidades padrões e genéricas do processo selecionado.

          Nesta aba é possível liberar ou bloquear determinadas funcionalidades para o processo.

          Nota

          Para exibir esta aba clique com o botão direito no processo e selecione Opções de Acesso.


          Aba: Campos

          Exibe os campos dos processos metadado.

          Nota

          Para exibir esta aba clique com o botão direito no processo e selecione Opções de Acesso.

          Para liberar ou bloquear acesso à determinados *campos do processo é necessário efetuar um duplo clique na coluna check da grade de campos.

          É possível também, clicar no cabeçalho desta mesma coluna para alterar o tipo de permissão para todas as colunas da grade. A cada clique nesta coluna é alterado o tipo de permissão para o campo, sendo:

            • Lupa: permite apenas visualizar o campo, mas não permite edição do mesmo.
            • Cancelado: não permite visualizar o campo, sendo assim, não permite edição do mesmo,
            • Assinalado: permite visualizar o campo e permite a edição do mesmo.

                         * Somente campos que não são chaves primárias e não são obrigatórios poderão ser alterados.









          CONTEÚDO

          01. VISÃO GERAL

          Este programa promove a manutenção de acesso às tabelas por usuários ou grupos para utilização da Pesquisa Relacional do Logix .

          O programa Log5510 é acessado pelo cockpit do programa de Administração Logix - Log05050.

          A pesquisa relacional é uma ferramenta que permite ao usuário criar suas próprias visões por meio de uma interface intuitiva e sem a necessidade de programação. O usuário cria os seus modelos de pesquisa e pode salvá-lo em sua área de trabalho.

          A pesquisa relacional é baseada nos relacionamentos das tabelas Logix, permitindo que as informações sejam apresentadas em múltiplas janelas ou em uma única janela de forma dinâmica, por meio de relacionamentos pré-estabelecidos.

          02. EXEMPLO DE UTILIZAÇÃO

          Ao acessar o programa Permissão de Acesso às Tabelas - Log5510 e realizar uma pesquisa, será solicitado para quem será a permissão, que pode ser para um Usuário ou um Grupo de usuários:

           

          03. TELA PERMISSÃO DE ACESSO ÀS TABELAS

          Outras Ações / Ações relacionadas

          Ação Descrição

          Usuário/grupo

          Código do usuário ou grupo.

          Opção

          Indica se libera ou bloqueia os programas para o usuário/grupo:

            • Liberar tudo;
            • Bloquear tudo.

          Ir para a tabela

          Localiza e posiciona a tabela informada na árvore de tabelas.
          Menu Logix

          Árvore de tabelas Logix. Nesta árvore encontram-se todos as tabelas cadastrados no menu Logix.

          Para alterar as permissões, deve-se prosseguir da seguinte forma:

                 Clicar com o botão direito do mouse sobre o item no qual deseja alterar a permissão.

                 As opções disponíveis para alteração de permissão são:

            • Liberar acesso: clique para liberar acesso total para a tabela;
            • Bloquear acesso: clique para bloquear acesso total para a tabela;
            • Opções de acesso: clique para exibir e permitir liberar ou bloquear determinados campos da tabela.


          Nota

          As liberações e bloqueios às TABELAS do Logix estão diretamente direcionadas para uso da PESQUISA RELACIONAL.

          Opções de acesso

          Exibe os campos disponíveis que permitem manipulação de acesso.

          Nesta área é possível liberar ou bloquear determinados campos para o acesso do usuário/grupo.

          Nota

          Para exibir esta área clique com o botão direito no processo e selecione Opções de Acesso.









          CONTEÚDO

          01. VISÃO GERAL

          Este programa efetua o bloqueio de acesso de usuários no sistema Logix.

          O programa Log00081 é acessado pelo cockpit do programa de Administração Logix - Log05050.


          02. EXEMPLO DE UTILIZAÇÃO

          No programa Log00081 é possível bloquear e desbloquear os usuários do produto.

          Também, existe um atalho na Barra de Ferramentas para criar os Motivos dos Bloqueios.


          03. TELA USUÁRIOS BLOQUEADOS

          Outras Ações / Ações relacionadas

          Ação Descrição
          Desbloquear

          Indica se libera ou não o usuário.

          Usuário

          Código do usuário.

          Motivo

          Motivo do bloqueio.

          Descrição

          Descrição do bloqueio.

          Início do bloqueio

          Data de início do bloqueio.

          Fim do bloqueio

          Data de término do bloqueio.
          Usuário bloqueio Usuário que realizou o bloqueio.

          Obs.

          Observações do bloqueio.

          Data bloqueio

          Data em que foi realizado o bloqueio.






            ↑ início

          4. Consentimento

          A lei estabelece que o consentimento é a manifestação livre, informada e inequívoca pela qual o titular concorda com o tratamento de seus dados pessoais para uma determinada finalidade.

          Deve-se identificar a necessidade da solicitação do consentimento e elaborá-lo, por meio de documentação física, atentando para os princípios previstos na lei em relação ao tratamento dos dados pessoais. 

          O cliente, como controlador, é responsável pela:

          • Elaboração: criação do termo de consentimento, assegurando todos os princípios previstos na lei e necessidade de uso dos dados pessoais pela empresa.
          • Solicitação: inserir a solicitação do consentimento ao titular nos processos da empresa, por exemplo, na contratação de funcionários e serviços.
          • Gestão: controlar o consentimento dos titulares e a atualização do termo de consentimento em caso de atualizações ou mudanças na finalidade do tratamento dos dados pessoais, que neste caso deve ser solicitado novo consentimento ao titular, que possui o direito de revogá-lo.

          É importante lembrar que o cliente, como controlador, deverá destacar no termo de consentimento quais produtos compartilha dados dentro e fora da organização.

          Atenção!

          Dado pessoal de criança e adolescente: O Estatuto da Criança e do Adolescente (ECA) considera criança a pessoa até 12 anos de idade incompletos e adolescente aquela entre 12 e 18 anos de idade. A   LGPD apresenta uma sessão específica sobre os dados de crianças e adolescentes, portanto, para titulares menores de idade deve existir um consentimento específico e claro dos pais ou responsável legal.

            ↑ início

          5. Protocolos

          Assegurar a proteção das informações nas integrações, de ponta a ponta, em relação aos protocolos utilizados pela empresa nas comunicações realizadas. O cliente, como controlador, é o responsável em assegurar esta proteção/segurança.

          No sentido de orientar e auxiliar os clientes, a TOTVS sugere algumas validações:

          • Verificar se a empresa faz uso de protocolos inseguros como: HTTP, ODBC, FTP, Telnet, etc.
          • Avaliar a substituição destes por protocolos SEGUROS: HTTPS, FTPS, SSH, etc.
          • Manter desativado por padrão os protocolos inseguros, caso não possua alternativa de substituição.
          Impacto no produto

            Estudo para avaliação dos procedimentos e configurações de conexões utilizando o protocolo SSL/TLS possibilitou o entendimento das anomalias encontradas ao longo do parque de clientes em produção. Apresentaremos abaixo alguns passos do estudo junto com os argumentos utilizados na nova implementação que estará disponível a partir da versão 13.1.3.26 e 13.2.3.26.

            Para obter maiores informações sobre a família de versões do protocolo SSL/TLS acesse página Utilizando SSL – Secure Socket Layer. Para informações sobre as sessões, chaves e valores das configurações SSL/TLS no AppServer acesse a página Configuração SSL no AppServer.

            Utilizamos no processo de investigação a última versão do TOTVS | Application Server disponível no portal de downloads e atualizações da TOTVS, correspondente ao código P12 Windows x86 versão 13.2.3.25. Também utilizamos a ferramenta OpenSSL 1.1.0f para simular o par de conexão, quer seja server quer client.

            Disponibilidade

            O estudo foi realizado utilizando a versão do Application Server 13.1.3.25 e 13.2.3.25. As alterações propostas somente estarão disponíveis a partir da versão do Application Server 13.1.3.26 e 13.2.3.26.

            1. Porque o uso do TryProtocols?

            1.1. Preparação do Ambiente

            Iniciamos com a configuração do Application Server (AppServer) na tentativa de estabelcer conexões seguras SSL/TLS na versão TLS1.2. Essa versão de protocolo é a mais segura disponível. Abaixo a sessão SSLConfigure utilizada. Observe que não habilitaremos a chave TryProtocols.

            [SSLConfigure]
Verbose = 1
SSL2    = 0
SSL3    = 0
TLS1    = 3
Bugs    = 0
State   = 1
TryProtocols = 0

            Codificamos um pequeno programa ADVPL utilizando a função HTTPSGet. A proposta é realizar uma solicitação simples de conexão sem a necessidade de aguardarmos a resposta desse servidor, pois o objetivo é avaliar o processo de conexão:

            HTTPSGet 
            #include 'protheus.ch'
#include 'parmtype.ch'

user function GetSSL01()
 Local cURL := "https://127.0.0.1:8443"
 Local aHeadOut := {}
 Local cHeadRet := ""
 Local cGetRet := ""
 
 AAdd( aHeadOut, 'User-Agent: Mozilla/4.0 (compatible; Protheus ' + GetBuild() + ')' )
 cGetRet := HTTPSGet( cURL, "", "", "", "WSDL", 120, aHeadOut, @cHeadRet )
if Empty( cGetRet )
 conout( "Fail HTTPSGet" )
 else
 conout( "OK HTTPSGet" )
 varinfo( "WebPage", cGetRet )
 endif
 
 varinfo( "Header", cHeadRet )
return

            Iniciamos a ferramenta OpenSSL de forma a simular um servidor que aceita somente conexões SSL/TLS na versão TLS1.2, conforme o comando abaixo:

            openssl s_server -4 -key localhost-key.pem -cert localhost-cert.pem -accept 8443 -state -msg -security_debug -nbio -tls1_2

            1.2. Execução para Ambientação

            Executando o programa ADVPL GetSSL01 observamos que houve sucesso na conexão entre o AppServer e o OpenSSL Server. O log da console AppServer apresenta várias informações importantes na análise, por exemplo:

            • Configuração SSL/TLS carregada pela aplicação → linha 32:
              [INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (3)

            • Versão do protocolo utilizado na conexão → linha 48:
              [INFO ][SSL] [tSSLSocketAPI] Using TLS1.2 protocol.

            • Configuração SSL/TLS utilizada no processo de comunicação → linha 53:
              [INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (3)
            • Resultado da conexão → linha 69 e 70:
              [INFO ][SSL] SSL callback where:[32] ret:[1] state:[SSL negotiation finished successfully]
              [INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.

            Abaixo o registro do console:

            Log AppServer TLS1.2 (client) vs OpenSSL TLS1.2 (server) 
            Windows Operating System version 6.1.7601 Service Pack 1
[INFO ][SERVER] [Thread 6752] [SMARTHEAP] Version 8.0.0
*** TOTVS S.A. ***
*** www.totvs.com.br ***
* TOTVS - Build 7.00.131227A - Nov 23 2017 - 13:23:07 NG
* Build: 32 bits
* RPO Format: 32 bits
* SVN Revision: 10324 - 15733 - 1956
* Build Version: 13.2.3.25
'Ambiente de teste para comunicacao SSL/TLS' console mode.
Press Ctrl+Break to terminate.
*** STARTING SERVER WITH DEBUG OF USED MEMORY PER THREAD
*** STARTING SERVER WITH MAXIMUM STRING SIZE LIMIT SET TO 20 MB. ***
---------------- OS System Info -----------------------------------------------
OS Version .........: Windows 7 [Version 6.1.7601]
OS Platform ........: Windows NT Based (x64)
OS Version Info ....: Service Pack 1
-------------------------------------------------------------------------------
---------------- OS Memory Info -----------------------------------------------
Physical memory . 8025.59 MB. Used 7078.12 MB. Free 947.48 MB.
Paging file ..... 16049.37 MB. Used 12385.17 MB. Free 3664.20 MB.
-------------------------------------------------------------------------------
[INFO ][SERVER] [Thread 6752] APP Virtual Address Allocation Limit .... 4095.88MB.
[INFO ][SERVER] [Thread 6752] Memory Monitor Virtual Address LIMIT .... 4095.88MB.
Http server is ready.
 Root path is c:\totvs\p12_windows_x86\protheus_data\web\
 Listening port 8888
[INFO ][SSL] [tSSLSocketAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using TLS1.2 protocol.
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (3)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] Setting Certificates
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] cert (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] key (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketAPI][Initialize] End handshake.
Https server is ready.
 Listening port 443 (default)
[INFO ][SERVER] Application PID ......... [10864]
[INFO ][SERVER] Application Main Thread .. [6752]
[INFO ][SERVER] [Thread 6752] Application Server started on port 8612
[08/12/2017 10:11:36] Server started.
[WARN ][SERVER] [Thread 1496] [GENERAL] INACTIVETIMEOUT = 99999 seconds is ON.
[INFO ][SERVER] [08/12/2017 10:19:41] Starting Program U_GETSSL01 Thread 1496 (rinaldo,TEC-CATROQUE)
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using TLS1.2 protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (3)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv3 write client hello A
[INFO ][SSL] SSL_connect:SSLv3 read server hello A
[INFO ][SSL] SSL_connect:SSLv3 read server certificate A
[INFO ][SSL] SSL_connect:SSLv3 read server key exchange A
[INFO ][SSL] SSL_connect:SSLv3 read server done A
[INFO ][SSL] SSL_connect:SSLv3 write client key exchange A
[INFO ][SSL] SSL_connect:SSLv3 write change cipher spec A
[INFO ][SSL] SSL_connect:SSLv3 write finished A
[INFO ][SSL] SSL_connect:SSLv3 flush data
[INFO ][SSL] SSL_connect:SSLv3 read server session ticket A
[INFO ][SSL] SSL_connect:SSLv3 read finished A
[INFO ][SSL] SSL callback where:[32] ret:[1] state:[SSL negotiation finished successfully]
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.

            1.3. Execução com Full Protocols

            Se adotarmos uma configuração no AppServer que habilite além do TLS1.2 também os protocoloos SSL2 e SSL3, pois intuitivamente estaríamos habilitando todo conjunto de protocolos disponíveis na aplicação (veremos mais adiante que essa informação é irregular):

            [SSLConfigure]
Verbose = 1
SSL2    = 1
SSL3    = 1
TLS1    = 3
Bugs    = 0
State   = 1
TryProtocols = 0

            Ao executar novamente o mesmo programa ADVPL temos como resultado um erro na tentativa de conexão. Observe que a aplicação fez uso do primeiro conjunto de protocolos diponíveis na aplicação (SSL3+SSL2), em um única tentativa, linha 48.

            Tecnicamente, o procedimento de conexão neste contexto de configuração utiliza uma função (recurso operacional com lista de comandos para execução) da biblioteca OpenSSL que providencia uma negociação quanto a versão do protocolo as partes poderão estabelecer. Não significa que está utilizando uma versão identificada por SSL3 e SSL2, mas que tratará uma negociação entre o conjunto de protocolos disponíveis e habilitados.

            Protocolos SSL/TLS

            O conjunto de protocolos disponíveis pela biblioteca OpenSSL, em ordem crescente de grau de segurança, é SSL2, SSL3, TLS1.0, TLS1.1 e TLS1.2. Cada versão estabelece um conjunto de regras, transações, cifras e protocolos com objetivo de melhorar os requisitos de segurança das versões anteriores.

            Observe que na configuração da aplicação habilitamos um conjunto parcial de protocolos. Também, note que há um descontinuidade dentre as versões do protocolo, ou seja, entre os graus de segurança:

            SSL2 → SS3 → ..?.. → ..?.. → TLS 1.2

            A biblioteca OpenSSL sugere que quando for utilizado o método genérico, que providência uma negociação da versão disponível para conexão, não haja descontinuidade nas versões dos protocolos ou graus de segurança. Por outro lado, somente deve ser utilizada a habilitação de versões quando utilizarmos os métodos objetivos das versões, ou seja, quando o método é direcionado para uma versão específica, como ocorrido no teste do primeiro contexto deste artigo.

            Log AppServer SSL2, SSL3 e TLS 1.2 (client) vs OpenSSL TLS1.2 (server) 
            Windows Operating System version 6.1.7601 Service Pack 1
[INFO ][SERVER] [Thread 6944] [SMARTHEAP] Version 8.0.0
*** TOTVS S.A. ***
*** www.totvs.com.br ***
* TOTVS - Build 7.00.131227A - Nov 23 2017 - 13:23:07 NG
* Build: 32 bits
* RPO Format: 32 bits
* SVN Revision: 10324 - 15733 - 1956
* Build Version: 13.2.3.25
'Ambiente de teste para comunicacao SSL/TLS' console mode.
Press Ctrl+Break to terminate.
*** STARTING SERVER WITH DEBUG OF USED MEMORY PER THREAD
*** STARTING SERVER WITH MAXIMUM STRING SIZE LIMIT SET TO 20 MB. ***
---------------- OS System Info -----------------------------------------------
OS Version .........: Windows 7 [Version 6.1.7601]
OS Platform ........: Windows NT Based (x64)
OS Version Info ....: Service Pack 1
-------------------------------------------------------------------------------
---------------- OS Memory Info -----------------------------------------------
Physical memory . 8025.59 MB. Used 7133.06 MB. Free 892.53 MB.
Paging file ..... 16049.37 MB. Used 12504.54 MB. Free 3544.83 MB.
-------------------------------------------------------------------------------
[INFO ][SERVER] [Thread 6944] APP Virtual Address Allocation Limit .... 4095.88MB.
[INFO ][SERVER] [Thread 6944] Memory Monitor Virtual Address LIMIT .... 4095.88MB.
Http server is ready.
 Root path is c:\totvs\p12_windows_x86\protheus_data\web\
 Listening port 8888
[INFO ][SSL] [tSSLSocketAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using SSL3+SSL2 protocol.
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (1), SSL3 (1), TLS1 (3)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] Setting Certificates
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] cert (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] key (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketAPI][Initialize] End handshake.
Https server is ready.
 Listening port 443 (default)
[INFO ][SERVER] Application PID ......... [4256]
[INFO ][SERVER] Application Main Thread .. [6944]
[INFO ][SERVER] [Thread 6944] Application Server started on port 8612
[08/12/2017 10:21:14] Server started.
[WARN ][SERVER] [Thread 11860] [GENERAL] INACTIVETIMEOUT = 99999 seconds is ON.
[INFO ][SERVER] [08/12/2017 10:21:22] Starting Program U_GETSSL01 Thread 11860 (rinaldo,TEC-CATROQUE)
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketClientAPI] Using SSL3+SSL2 protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (1), SSL3 (1), TLS1 (3)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv2/v3 write client hello A
[INFO ][SSL] SSL3 alert read:fatal:handshake failure
[INFO ][SSL] SSL_connect:error in SSLv2/v3 read server hello A
[ERROR][SSL] SSL erro = -1
[ERROR][SSL] SSL code = 336032784
[ERROR][SSL] SSL description = error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
[ERROR][SSL] Failed Handshake SSL.

            1.4. Prática da Solução

            A prática atual para solução do problema de conexão SSL/TLS no AppServer é a habilitação da chave TryProtocols na sessão [SSLConfigure] da configuração:

            [SSLConfigure]
Verbose = 1
SSL2    = 1
SSL3    = 1
TLS1    = 3
Bugs    = 0
State   = 1
TryProtocols = 1

            Ao executar novamente o mesmo programa ADVPL, temos como resultado o sucesso na conexão, porém, podemos observar os 2 (duas) tentativas de conexão.

            • Inicio da execução do programa → linha 45

            • Identificação do protocolo da primeira tentativa de conexão → linha 48
              [INFO ][SSL] [tSSLSocketClientAPI] Using SSL3+SSL2 protocol.

            • Habilitação de protocolos da primeira tentativa de conexão → linha 52
              [INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (1), SSL3 (1), TLS1 (3)

            • Resultado da primeira conexão → linha 63 e 64
              [ERROR][SSL] SSL description = error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
              [ERROR][SSL] Failed Handshake SSL.

            • Identificação do protocolo da segunda tentativa de conexão → 67
              [INFO ][SSL] [tSSLSocketAPI] Using TLS1.2 protocol.

            • Habilitação de protocolos da segunda tentativa de conexão → linha 72
              [INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (3)
            • Resultado da segunda conexão → linha 88 e 89
              [INFO ][SSL] SSL callback where:[32] ret:[1] state:[SSL negotiation finished successfully]
              [INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.

            Abaixo o registro do console:

            Log AppServer All TryProtocols (client) vs OpenSSL TLS1.2 (server) 
            Windows Operating System version 6.1.7601 Service Pack 1
[INFO ][SERVER] [Thread 576] [SMARTHEAP] Version 8.0.0
*** TOTVS S.A. ***
*** www.totvs.com.br ***
* TOTVS - Build 7.00.131227A - Nov 23 2017 - 13:23:07 NG
* Build: 32 bits
* RPO Format: 32 bits
* SVN Revision: 10324 - 15733 - 1956
* Build Version: 13.2.3.25
'Ambiente de teste para comunicacao SSL/TLS' console mode.
Press Ctrl+Break to terminate.
*** STARTING SERVER WITH DEBUG OF USED MEMORY PER THREAD
*** STARTING SERVER WITH MAXIMUM STRING SIZE LIMIT SET TO 20 MB. ***
---------------- OS System Info -----------------------------------------------
OS Version .........: Windows 7 [Version 6.1.7601]
OS Platform ........: Windows NT Based (x64)
OS Version Info ....: Service Pack 1
-------------------------------------------------------------------------------
---------------- OS Memory Info -----------------------------------------------
Physical memory . 8025.59 MB. Used 7120.40 MB. Free 905.20 MB.
Paging file ..... 16049.37 MB. Used 12659.12 MB. Free 3390.25 MB.
-------------------------------------------------------------------------------
[INFO ][SERVER] [Thread 576] APP Virtual Address Allocation Limit .... 4095.88 MB.
[INFO ][SERVER] [Thread 576] Memory Monitor Virtual Address LIMIT .... 4095.88 MB.
Http server is ready.
 Root path is c:\totvs\p12_windows_x86\protheus_data\web\
 Listening port 8888
[INFO ][SSL] [tSSLSocketAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using SSL3+SSL2 protocol.
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (1), SSL3 (1), TLS1 (3)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] Setting Certificates
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] cert (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] key (C:\Totvs\P12_Windows_x86\rotheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketAPI][Initialize] End handshake.
Https server is ready.
 Listening port 443 (default)
[INFO ][SERVER] Application PID ......... [6288]
[INFO ][SERVER] Application Main Thread .. [576]
[INFO ][SERVER] [Thread 576] Application Server started on port 8612
[08/12/2017 10:39:50] Server started.
[WARN ][SERVER] [Thread 4656] [GENERAL] INACTIVETIMEOUT = 99999 seconds is ON.
[INFO ][SERVER] [08/12/2017 10:40:08] Starting Program U_GETSSL01 Thread 4656 (rinaldo,TEC-CATROQUE)
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketClientAPI] Using SSL3+SSL2 protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (1), SSL3 (1), TLS1 (3)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv2/v3 write client hello A
[INFO ][SSL] SSL3 alert read:fatal:handshake failure
[INFO ][SSL] SSL_connect:error in SSLv2/v3 read server hello A
[ERROR][SSL] SSL erro = -1
[ERROR][SSL] SSL code = 336032784
[ERROR][SSL] SSL description = error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
[ERROR][SSL] Failed Handshake SSL.
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using TLS1.2 protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (3)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv3 write client hello A
[INFO ][SSL] SSL_connect:SSLv3 read server hello A
[INFO ][SSL] SSL_connect:SSLv3 read server certificate A
[INFO ][SSL] SSL_connect:SSLv3 read server key exchange A
[INFO ][SSL] SSL_connect:SSLv3 read server done A
[INFO ][SSL] SSL_connect:SSLv3 write client key exchange A
[INFO ][SSL] SSL_connect:SSLv3 write change cipher spec A
[INFO ][SSL] SSL_connect:SSLv3 write finished A
[INFO ][SSL] SSL_connect:SSLv3 flush data
[INFO ][SSL] SSL_connect:SSLv3 read server session ticket A
[INFO ][SSL] SSL_connect:SSLv3 read finished A
[INFO ][SSL] SSL callback where:[32] ret:[1] state:[SSL negotiation finished successfully]
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.

            1.5. Temos a Solução?

            Esse comportamento nos induz ao uso indiscriminado dos métodos objetivos da biblioteca OpenSSL, pois associa a versão do protocolo requerida e um método direto e objetivo, porém, na aplicação a disponibilização de conexão por múltiplas versões gera a necessidade de controle de loop de retentativas. Vamos então avaliar o uso de conexão TLS1.0 contra um servidor que disponibilize somente a versão TLS1.1:

            Configuramos o AppServer como:

            [SSLConfigure]
Verbose = 1
SSL2    = 0
SSL3    = 0
TLS1    = 1
Bugs    = 0
State   = 1
TryProtocols = 1

            Iniciamos a ferramenta OpenSSL com a configuração que fornece um serviço TLS 1.1:

            openssl s_server -4 -key localhost-key.pem -cert localhost-cert.pem -accept 8443 -state -msg -security_debug -nbio -tls1_1

            Ao executar o mesmo programa ADVPL veremos que a conexão ocorrerá com sucesso, porém, há um conjunto de tentativas que falharam. Note que não deveria ter havido sucesso na conexão, uma vez que não foi permita habilitação do protocolo TLS 1.0 no AppServer (TLS1 = 1, que significa habilitação para versão TLS 1.0).

            • Inicio da execução do programa → linha 45

            • Identificação do protocolo da primeira tentativa de conexão → linha 48
              [INFO ][SSL] [tSSLSocketAPI] Using TLS1.0 protocol.

            • Habilitação de protocolos da primeira tentativa de conexão → linha 53
              [INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (1)

            • Resultado da primeira conexão → linha 65 e 66
              [ERROR][SSL] SSL description = error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure
              [ERROR][SSL] Unable to send data. Error syscall.

            • Identificação do protocolo da segunda tentativa de conexão → 69
              [INFO ][SSL] [tSSLSocketAPI] Using TLS1.2 protocol.

            • Habilitação de protocolos da segunda tentativa de conexão → linha 74
              [INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (3)

            • Resultado da segunda conexão → linha 84 e 85
              [ERROR][SSL] SSL description = error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
              [ERROR][SSL] Failed Handshake SSL.

            • Identificação do protocolo da terceira tentativa de conexão → 88
              [INFO ][SSL] [tSSLSocketAPI] Using TLS1.1 protocol.

            • Habilitação de protocolos da terceira tentativa de conexão → linha 93
              [INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (2)

            • Resultado da terceira conexão → linha 110
              [INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.

            Resumindo, o AppServer tentou realizar a conexão que estava configurada TLS 1.0, não obtendo sucesso partiu para uma tentativa de conexão não configurada TLS 1.2, e com seu insucesso tentou o protocolo anterior TLS 1.1 que acabou fechando a conexão. Na melhor das hipóteses mascarou um erro de configuração da aplicação.

            Abaixo o registro do console:

            Log AppServer TLS1.0 (client) vs OpenSSL TLS1.1 (server) 
            Windows Operating System version 6.1.7601 Service Pack 1
[INFO ][SERVER] [Thread 5072] [SMARTHEAP] Version 8.0.0
*** TOTVS S.A. ***
*** www.totvs.com.br ***
* TOTVS - Build 7.00.131227A - Nov 23 2017 - 13:23:07 NG
* Build: 32 bits
* RPO Format: 32 bits
* SVN Revision: 10324 - 15733 - 1956
* Build Version: 13.2.3.25
'Ambiente de teste para comunicacao SSL/TLS' console mode.
Press Ctrl+Break to terminate.
*** STARTING SERVER WITH DEBUG OF USED MEMORY PER THREAD
*** STARTING SERVER WITH MAXIMUM STRING SIZE LIMIT SET TO 20 MB. ***
---------------- OS System Info -----------------------------------------------
OS Version .........: Windows 7 [Version 6.1.7601]
OS Platform ........: Windows NT Based (x64)
OS Version Info ....: Service Pack 1
-------------------------------------------------------------------------------
---------------- OS Memory Info -----------------------------------------------
Physical memory . 8025.59 MB. Used 7146.13 MB. Free 879.47 MB.
Paging file ..... 16049.37 MB. Used 13021.99 MB. Free 3027.38 MB.
-------------------------------------------------------------------------------
[INFO ][SERVER] [Thread 5072] APP Virtual Address Allocation Limit .... 4095.88MB.
[INFO ][SERVER] [Thread 5072] Memory Monitor Virtual Address LIMIT .... 4095.88MB.
Http server is ready.
 Root path is c:\totvs\p12_windows_x86\protheus_data\web\
 Listening port 8888
[INFO ][SSL] [tSSLSocketAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using TLS1.0 protocol.
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] Setting Certificates
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] cert (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] key (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketAPI][Initialize] End handshake.
Https server is ready.
 Listening port 443 (default)
[INFO ][SERVER] Application PID ......... [6648]
[INFO ][SERVER] Application Main Thread .. [5072]
[INFO ][SERVER] [Thread 5072] Application Server started on port 8612
[08/12/2017 11:04:13] Server started.
[WARN ][SERVER] [Thread 9072] [GENERAL] INACTIVETIMEOUT = 99999 seconds is ON.
[INFO ][SERVER] [08/12/2017 11:04:24] Starting Program U_GETSSL01 Thread 9072 (rinaldo,TEC-CATROQUE)
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using TLS1.0 protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv3 write client hello A
[INFO ][SSL] SSL3 alert read:fatal:protocol version
[INFO ][SSL] SSL_connect:failed in SSLv3 read server hello A
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.
[INFO ][SSL] SSL_connect:failed in SSLv3 read server hello A
[ERROR][SSL] SSL erro = -1
[ERROR][SSL] SSL code = 336191717
[ERROR][SSL] SSL description = error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure
[ERROR][SSL] Unable to send data. Error syscall.
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using TLS1.2 protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (3)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv3 write client hello A
[INFO ][SSL] SSL3 alert write:fatal:protocol version
[INFO ][SSL] SSL_connect:error in SSLv3 read server hello A
[ERROR][SSL] SSL erro = -1
[ERROR][SSL] SSL code = 336130315
[ERROR][SSL] SSL description = error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
[ERROR][SSL] Failed Handshake SSL.
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using TLS1.1 protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1 (2)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv3 write client hello A
[INFO ][SSL] SSL_connect:SSLv3 read server hello A
[INFO ][SSL] SSL_connect:SSLv3 read server certificate A
[INFO ][SSL] SSL_connect:SSLv3 read server key exchange A
[INFO ][SSL] SSL_connect:SSLv3 read server done A
[INFO ][SSL] SSL_connect:SSLv3 write client key exchange A
[INFO ][SSL] SSL_connect:SSLv3 write change cipher spec A
[INFO ][SSL] SSL_connect:SSLv3 write finished A
[INFO ][SSL] SSL_connect:SSLv3 flush data
[INFO ][SSL] SSL_connect:SSLv3 read server session ticket A
[INFO ][SSL] SSL_connect:SSLv3 read finished A
[INFO ][SSL] SSL callback where:[32] ret:[1] state:[SSL negotiation finished successfully]
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.

            2. Habilitação de Range de Versões

            2.1. Introdução

            Como já informado anteriormente, o conjunto de protocolos disponíveis pela biblioteca OpenSSL, em ordem crescente de grau de segurança, é SSL2, SSL3, TLS1.0, TLS1.1 e TLS1.2. Também, a biblioteca sugere que não haja descontinuidade na habilitação de versões quando utilizado o método de negociação de versão do protocolo SSL/TLS. Ao utilizar métodos que direcionem a conexão para versões específicas não deve ser utilizado os recursos de habilitação de protocolo. Os protocolos TLS são nada mais que a continuidade do desenvolvimento dos protocolos SSL, de forma que a versão TLS1.0 corresponderia hipoteticamente à versão SSL4.

            Inseguro

            Em decorrência a um conjunto de referências bem documentadas sobre sucessos na quebra do protocolo e, por consequência, sua segurança, não é recomendada a utilização das versões SSL2, SSL3 e TLS1.0 em ambiente de produção. São consideradas versões inseguras do protocolo SSL/TLS. Recomenda-se a utilização da versões TLS1.1 e TLS1.2.

            Note que uma configuração importante mas até aqui não abordada é a impossibilidade atual de habilitar o uso de versões TLS concomitantemente. Nem todos clientes e serviços disponíveis no parque de produção da aplicação, e que fazem integração ao AppServer, estão atualizados com a versão TLS1.2. Isso quer dizer que o AppServer atuando como um servidor de informações pode e deve tentar manter um maior grau de segurança possível em suas conexões. No papel de consumido de informação, não é rara a necessidade de realizar conexões com mais de um servidor cada qual com uma versão distinta do protocolo.

            Há, portanto, necessidade de habilitar a utilização dos protocolos TLS1.1 e TLS1.2 e também manter continuidade entre o menor e maior grau de segurança, correspondente a versão de protocolo utilizado.

            A correção de conexões SSL proposta e incluída a partir da versão da TOTVS | Application Server 13.1.3.26 e 13.2.3.26 estabelece o uso de novas chaves de habilitação de protocolo TLS, sendo utilizado somente valores 1 (habilitação) e 0 (desabilitação):

            [SSLConfigure]
TLS1_0 = 0
TLS1_1 = 1
TLS1_2 = 1

            A chave antiga TLS1 está mantida no modo deprecated. Isso significa que a aplicação carregará a informação disponível mantendo compatibilidade nas versões anteriores. Nos casos que estejam presentes a chave TLS1 e qualquer das chaves novas, o conteúdo da chave antiga será desconsiderada integralmente. Ou seja, mesmo que a chave TLS1 esteja configurada para o protocolo TLS1.2 (TLS1 = 3), caso encontre somente a chave TLS1_0 no arquivo INI o protocolo TLS1.2 será desabilitado da conexão.

            Não haverá mais necessidade da chave TryProtocols. O mecanismo de retentativa de conexão com pooling de versão de protocolo será responsabilidade do método de negociação de versão. Ainda que seja encontrada a chave TryProtocols no arquivo INI ela será desprezada.

            2.2. Ambiente e Teste com TLS 1.2

            Passemos a realizar testes com a nova implementação das conexões SSL/TLS sob o mesmo contexto anterior, ou seja, partiremos para uma conexão TLS1.2 única e, posteriormente, adicionaremos um conjunto conjugado de versões. Ao final faremos algumas análises quanto a premissas de configuração.

            Cabe salientar que a nova implementação utilizou como base a mesma versão utilizada nos testes anteriores, isso significa que nenhuma funcionalidade foi adiciona ou removida entre os binários.

            Utilização dos protocolos seguros TLS1.1 e TLS1.2:

            [SSLConfigure]
Verbose = 1
SSL2    = 0
SSL3    = 0
TLS1_0  = 0
TLS1_1  = 1
TLS1_2  = 1
Bugs    = 0
State   = 1

            Iniciamos o simulador de servidor OpenSSL com a possiblildade de conexões somente no protocolo TLS1.2:

            openssl s_server -4 -key localhost-key.pem -cert localhost-cert.pem -accept 8443 -state -msg -security_debug -nbio -tls1_2

            Executamos o mesmo programa ADVPL anterior. Temos como resultado o sucesso na conexão:

            • Configuração SSL/TLS carregada pela aplicação → linha 36:
              [INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1.0 (0), TLS1.1 (1), TLS1.2 (1)

            • Configuração SSL/TLS utilizada no processo de comunicação → linha 57:
              [INFO ][SSL] [tSSLSocketClientAPI][Initialize] SSL2 (0), SSL3 (0), TLS1.0 (0), TLS1.1 (1), TLS1.2 (1)

            • Resultado da conexão → linha 73 e 74:
              [INFO ][SSL] SSL callback where:[32] ret:[1] state:[SSL negotiation finished successfully]
              [INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.

            Abaixo o registro do console:

            Log AppServer Novo TLS 1.1 TLS 1.2 (cliente) vs OpenSSL TLS 1.2 (server) 
            Windows Operating System version 6.1.7601 Service Pack 1
[INFO ][SERVER] [Thread 6920] *** NOT USING SMARTHEAP
*** TOTVS S.A. ***
*** www.totvs.com.br ***
* TOTVS - Build 7.00.131227A - Dec 7 2017 - 13:54:58 NG
* Build: 32 bits
* DEBUG VERSION
* RPO Format: 32 bits
* SVN Revision: 10394 - 15899 - 1956
* Build Version: 0.0.0
'Ambiente de teste para comunicacao SSL/TLS' console mode.
Press Ctrl+Break to terminate.
*** DEBUG VERSION WITH CRASH DUMP HANDLER
*** DEBUG VERSION WITH SYMBOLS INFORMATION
*** STARTING SERVER WITH DEBUG OF USED MEMORY PER THREAD
*** STARTING SERVER WITH MAXIMUM STRING SIZE LIMIT SET TO 20 MB. ***
---------------- OS System Info -----------------------------------------------
OS Version .........: Windows 7 [Version 6.1.7601]
OS Platform ........: Windows NT Based (x64)
OS Version Info ....: Service Pack 1
-------------------------------------------------------------------------------
---------------- OS Memory Info -----------------------------------------------
Physical memory . 8025.59 MB. Used 6975.31 MB. Free 1050.29 MB.
Paging file ..... 16049.37 MB. Used 13635.53 MB. Free 2413.84 MB.
-------------------------------------------------------------------------------
[INFO ][SERVER] [Thread 6920] APP Virtual Address Allocation Limit .... 4095.88MB.
[INFO ][SERVER] [Thread 6920] Memory Monitor Virtual Address LIMIT .... 4095.88MB.
[INFO ][SERVER] [Thread 9928] Crash Monitor BEGIN
Http server is ready.
 Root path is c:\totvs\p12_windows_x86\protheus_data\web\
 Listening port 8888
[INFO ][SSL] [tSSLSocketAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using SSL/TLS protocol.
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (0), SSL3 (0), TLS1.0 (0), TLS1.1 (1), TLS1.2 (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] Setting Certificates
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] cert (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] key (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketAPI][Initialize] End handshake.
Https server is ready.
 Listening port 443 (default)
[INFO ][SERVER] Application PID ......... [10296]
[INFO ][SERVER] Application Main Thread .. [6920]
[INFO ][SERVER] [Thread 6920] Application Server started on port 8612
[08/12/2017 11:53:39] Server started.
[WARN ][SERVER] [Thread 4492] [GENERAL] INACTIVETIMEOUT = 99999 seconds is ON.
[INFO ][SERVER] [08/12/2017 11:55:00] Starting Program U_GETSSL01 Thread 4492 (rinaldo,TEC-CATROQUE)
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketClientAPI] Using TLS/SSL protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] SSL2 (0), SSL3 (0), TLS1.0 (0), TLS1.1 (1), TLS1.2 (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv2/v3 write client hello A
[INFO ][SSL] SSL_connect:SSLv3 read server hello A
[INFO ][SSL] SSL_connect:SSLv3 read server certificate A
[INFO ][SSL] SSL_connect:SSLv3 read server key exchange A
[INFO ][SSL] SSL_connect:SSLv3 read server done A
[INFO ][SSL] SSL_connect:SSLv3 write client key exchange A
[INFO ][SSL] SSL_connect:SSLv3 write change cipher spec A
[INFO ][SSL] SSL_connect:SSLv3 write finished A
[INFO ][SSL] SSL_connect:SSLv3 flush data
[INFO ][SSL] SSL_connect:SSLv3 read server session ticket A
[INFO ][SSL] SSL_connect:SSLv3 read finished A
[INFO ][SSL] SSL callback where:[32] ret:[1] state:[SSL negotiation finished successfully]
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.

            2.2. Teste Full Protocols

            Habilitaremos agora todo o conjunto de protocolos:

            [SSLConfigure]
Verbose = 1
SSL2    = 1
SSL3    = 1
TLS1_0  = 1
TLS1_1  = 1
TLS1_2  = 1
Bugs    = 0
State   = 1

            Iniciamos o simulador de servidor OpenSSL com a possiblildade de conexões no protocolo TLS1.0 somente. Isso permite avaliar se a negociação conterá overhead desnecessário:

            openssl s_server -4 -key localhost-key.pem -cert localhost-cert.pem -accept 8443 -state -msg -security_debug -nbio -tls1

            Executamos o mesmo programa ADVPL anterior. Temos como resultado o sucesso na conexão. Observamos que houve apenas um ciclo de handshaking para o estabelecimento da conexão.

            • Configuração SSL/TLS carregada pela aplicação → linha 36:
              [INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (1), SSL3 (1), TLS1.0 (1), TLS1.1 (1), TLS1.2 (1)

            • Configuração SSL/TLS utilizada no processo de comunicação → linha 57:
              [INFO ][SSL] [tSSLSocketClientAPI][Initialize] SSL2 (1), SSL3 (1), TLS1.0 (1), TLS1.1 (1), TLS1.2 (1)

            • Resultado da conexão → linha 73 e 74:
              [INFO ][SSL] SSL callback where:[32] ret:[1] state:[SSL negotiation finished successfully]
              [INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.

            Abaixo o registro do console:

            Log AppServer Full (client) vs OpenSSL TLS 1.0 (server) 
            *** TOTVS S.A. ***
*** www.totvs.com.br ***
* TOTVS - Build 7.00.131227A - Dec 7 2017 - 13:54:58 NG
* Build: 32 bits
* DEBUG VERSION
* RPO Format: 32 bits
* SVN Revision: 10394 - 15899 - 1956
* Build Version: 0.0.0
'Ambiente de teste para comunicacao SSL/TLS' console mode.
Press Ctrl+Break to terminate.
*** DEBUG VERSION WITH CRASH DUMP HANDLER
*** DEBUG VERSION WITH SYMBOLS INFORMATION
*** STARTING SERVER WITH DEBUG OF USED MEMORY PER THREAD
*** STARTING SERVER WITH MAXIMUM STRING SIZE LIMIT SET TO 20 MB. ***
---------------- OS System Info -----------------------------------------------
OS Version .........: Windows 7 [Version 6.1.7601]
OS Platform ........: Windows NT Based (x64)
OS Version Info ....: Service Pack 1
-------------------------------------------------------------------------------
---------------- OS Memory Info -----------------------------------------------
Physical memory . 8025.59 MB. Used 6966.13 MB. Free 1059.46 MB.
Paging file ..... 16049.37 MB. Used 13714.11 MB. Free 2335.26 MB.
-------------------------------------------------------------------------------
[INFO ][SERVER] [Thread 8960] APP Virtual Address Allocation Limit .... 4095.88MB.
[INFO ][SERVER] [Thread 7808] Crash Monitor BEGIN
[INFO ][SERVER] [Thread 8960] Memory Monitor Virtual Address LIMIT .... 4095.88MB.
Http server is ready.
 Root path is c:\totvs\p12_windows_x86\protheus_data\web\
 Listening port 8888
[INFO ][SSL] [tSSLSocketAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using SSL/TLS protocol.
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (1), SSL3 (1), TLS1.0 (1), TLS1.1 (1), TLS1.2 (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] Setting Certificates
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] cert (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] key (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketAPI][Initialize] End handshake.
Https server is ready.
 Listening port 443 (default)
[INFO ][SERVER] Application PID ......... [11516]
[INFO ][SERVER] Application Main Thread .. [8960]
[INFO ][SERVER] [Thread 8960] Application Server started on port 8612
[08/12/2017 11:58:06] Server started.
[WARN ][SERVER] [Thread 11980] [GENERAL] INACTIVETIMEOUT = 99999 seconds is ON.
[INFO ][SERVER] [08/12/2017 11:58:18] Starting Program U_GETSSL01 Thread 11980 (rinaldo,TEC-CATROQUE)
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketClientAPI] Using TLS/SSL protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] SSL2 (1), SSL3 (1), TLS1.0 (1), TLS1.1 (1), TLS1.2 (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv2/v3 write client hello A
[INFO ][SSL] SSL_connect:SSLv3 read server hello A
[INFO ][SSL] SSL_connect:SSLv3 read server certificate A
[INFO ][SSL] SSL_connect:SSLv3 read server key exchange A
[INFO ][SSL] SSL_connect:SSLv3 read server done A
[INFO ][SSL] SSL_connect:SSLv3 write client key exchange A
[INFO ][SSL] SSL_connect:SSLv3 write change cipher spec A
[INFO ][SSL] SSL_connect:SSLv3 write finished A
[INFO ][SSL] SSL_connect:SSLv3 flush data
[INFO ][SSL] SSL_connect:SSLv3 read finished A
[INFO ][SSL] SSL callback where:[32] ret:[1] state:[SSL negotiation finished successfully]
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.

            Não podemos inferir pelo log do AppServer qual foi a versão do protocolo SSL/TLS estabelecida entre as partes. Podemos identificar qual o protocolo foi utilizado na conexão através do log da ferramenta OpensSSL. É possível verificar que a tratativa de conexão envolveu o TLS1.0:

            Log OpenSSL TLS 1.0 
            SSL_accept:SSLv3/TLS read client key exchange
<<< ??? [length 0005]
 16 03 01 00 30
SSL_accept:SSLv3/TLS read change cipher spec
<<< TLS 1.0Handshake [length 0010], Finished
 14 00 00 0c 85 30 a2 97 0a 7f 8d fb 35 6e 9b 48
SSL_accept:SSLv3/TLS read finished
>>> ??? [length 0005]
 14 03 01 00 01
>>> TLS 1.0ChangeCipherSpec [length 0001]
 01
SSL_accept:SSLv3/TLS write change cipher spec
>>> ??? [length 0005]
 16 03 01 00 30
>>> TLS 1.0Handshake [length 0010], Finished
 14 00 00 0c 72 91 fa a4 c2 01 97 0c 88 7d 0f 86
SSL_accept:SSLv3/TLS write finished

            2.3. Nova Implementação com Range Descontínuo

            Como proposta experimental configuramos o AppServer com um range de versões do protocolo SSL/TLS para avaliar os problemas encontrados.

            [SSLConfigure]
Verbose = 1
SSL2    = 1
SSL3    = 0
TLS1_0  = 0
TLS1_1  = 1
TLS1_2  = 1
Bugs    = 0
State   = 1

            Iniciamos o simulador de servidor OpenSSL com a possiblildade de conexões no protocolo TLS1.1 somente.

            openssl s_server -4 -key localhost-key.pem -cert localhost-cert.pem -accept 8443 -state -msg -security_debug -nbio -tls1_1

            Executando o mesmo programa ADVPL vemos que a conexão não consegue ser estabelecida satisfatoriamente. Ainda que a versão do protocolo TLS 1.1 esteja corretamente configurada, o fato de haver uma descontinuidade faz com que a comunicação se atrapalhe quanto as funcionalidades habilitadas para o conjunto selecionado.

            Segue o log para análise:

            AppServer SSL2, TLS1.1 e TLS1.2 (client) vs OpenSSL TLS1.1 (server) 
            Windows Operating System version 6.1.7601 Service Pack 1
[DEBUG][SERVER] Command Line Arguments - BEGIN...
[DEBUG][SERVER] [console] -> []
[DEBUG][SERVER] Command Line Arguments - END.
[INFO ][SERVER] [Thread 10524] *** NOT USING SMARTHEAP
*** TOTVS S.A. ***
*** www.totvs.com.br ***
* TOTVS - Build 7.00.131227A - Dec 7 2017 - 13:54:58 NG
* Build: 32 bits
* DEBUG VERSION
* RPO Format: 32 bits
* SVN Revision: 10394 - 15899 - 1956
* Build Version: 0.0.0
'Ambiente de teste para comunicacao SSL/TLS' console mode.
Press Ctrl+Break to terminate.
*** DEBUG VERSION WITH CRASH DUMP HANDLER
*** DEBUG VERSION WITH SYMBOLS INFORMATION
*** STARTING SERVER WITH DEBUG OF USED MEMORY PER THREAD
*** STARTING SERVER WITH MAXIMUM STRING SIZE LIMIT SET TO 20 MB. ***
---------------- OS System Info -----------------------------------------------
OS Version .........: Windows 7 [Version 6.1.7601]
OS Platform ........: Windows NT Based (x64)
OS Version Info ....: Service Pack 1
-------------------------------------------------------------------------------
---------------- OS Memory Info -----------------------------------------------
Physical memory . 8025.59 MB. Used 5703.16 MB. Free 2322.43 MB.
Paging file ..... 16049.37 MB. Used 10246.11 MB. Free 5803.26 MB.
-------------------------------------------------------------------------------
[INFO ][SERVER] [Thread 10524] APP Virtual Address Allocation Limit .... 4095.88 MB.
[INFO ][SERVER] [Thread 10524] Memory Monitor Virtual Address LIMIT .... 4095.88 MB.
[INFO ][SERVER] [Thread 7552] Crash Monitor BEGIN
Http server is ready.
 Root path is c:\totvs\p12_windows_x86\protheus_data\web\
 Listening port 8888
[INFO ][SSL] [tSSLSocketAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketAPI] Using SSL/TLS protocol.
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (1), SSL3 (0), TLS1.0 (0), TLS1.1 (1), TLS1.2 (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketAPI][Initialize] Setting Certificates
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] cert (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] [tSSLSocketAPI][SetCertificateFiles] key (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketAPI][Initialize] End handshake.
Https server is ready.
 Listening port 443 (default)
[INFO ][SERVER] Application PID ......... [9648]
[INFO ][SERVER] Application Main Thread .. [10524]
[INFO ][SERVER] [Thread 10524] Application Server started on port 8612
[08/12/2017 12:25:56] Server started.
[WARN ][SERVER] [Thread 10408] [GENERAL] INACTIVETIMEOUT = 99999 seconds is ON.
[INFO ][SERVER] [08/12/2017 12:28:54] Starting Program U_GETSSL01 Thread 10408 (rinaldo,TEC-CATROQUE)
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketClientAPI] Using TLS/SSL protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] SSL2 (1), SSL3 (0), TLS1.0 (0), TLS1.1 (1), TLS1.2 (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv2/v3 write client hello A
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.
[ERROR][SSL] SSL erro = -1
[ERROR][SSL] SSL code = 336040165
[ERROR][SSL] SSL description = error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure
[ERROR][SSL] Unable to send data. Error syscall.
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketClientAPI] Using TLS/SSL protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] SSL2 (1), SSL3 (0), TLS1.0 (0), TLS1.1 (1), TLS1.2 (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv2/v3 write client hello A
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.
[ERROR][SSL] SSL erro = -1
[ERROR][SSL] SSL code = 336040165
[ERROR][SSL] SSL description = error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure
[ERROR][SSL] Unable to send data. Error syscall.
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] starting handshake ..
[INFO ][SSL] [tSSLSocketClientAPI] Using TLS/SSL protocol.
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] KeyFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-key.pem)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] CertificateFile (C:\Totvs\P12_Windows_x86\Protheus_Data\certs\localhost\localhost-cert.pem)
[INFO ][SSL] SSL CIPHERS ALL
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] Bugs (0)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] SSL2 (1), SSL3 (0), TLS1.0 (0), TLS1.1 (1), TLS1.2 (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] State (1)
[INFO ][SSL] [tSSLSocketClientAPI][Initialize] End handshake (1)
[INFO ][SSL] SSL callback where:[16] ret:[1] state:[before/connect initialization]
[INFO ][SSL] SSL_connect:before/connect initialization
[INFO ][SSL] SSL_connect:SSLv2/v3 write client hello A
[INFO ][SSL] [tSSLSocketAPI][Connect] Connecting SSL OK.
[ERROR][SSL] SSL erro = -1
[ERROR][SSL] SSL code = 336040165
[ERROR][SSL] SSL description = error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure
[ERROR][SSL] Unable to send data. Error syscall.

            3. Conclusão

            Foram realizados uma série de testes contextualizando o AppServer como servidor e cliente em conexões SSL/TLS, apesar deste estudo apenas demonstrar o contexto cliente da nova implementação. Todos testes mostraram-se satisfatórios em relação ao estabelecimento de conexão conforme os critérios estabelecidos na biblioteca LibSSL e informados anteriormente.

            Um resumo dos elementos mais importantes apontados são:

            3.1. Range de Protocolos

            A habilitação de versões do protocolo SSL/TLS deve sempre especificar um menor e um maior grau de segurança, sendo que não deve haver descontinuidades entre a relação de protocolos. Ou seja, não é adimitido configurações na forma:

            [SSLConfigure]
SSL2   = 1
SSL3   = 0   <- Erro
TLS1_0 = 0   <- Erro
TLS1_1 = 1
TLS1_2 = 1

            Significa que esta configuração não funcionará? Não, significa que a construção da biblioteca de comunicação não tem como garantir a possibilidade de conexão frente a descontinuidade de range de protocolo. Os testes realizados envolveram toda cadeia de continuidade possível frente a servidores utilizando o protocolo TLS1.1 e TLS1.2. Também foram realizados testes com descontinuidades, alguns resultaram em sucesso outros em falhas ainda que sob habilitação do protocolo alvo do servidor.

            3.2. Protocolos Recomendados

            A configuração recomendada para aumentar o grau de confiança na comunicação é:

            [SSLConfigure]
SSL2   = 0
SSL3   = 0
TLS1_0 = 0
TLS1_1 = 1
TLS1_2 = 1

            3.3. TLS1 deprecated

            A chave TLS1 é mantida em modo de compatibilidade. Caso novas chaves sejam encontradas teremos a supressão das configurações contidas no TLS1:

            [SSLConfigure]
SSL2   = 1
SSL3   = 1
TLS1   = 3  <- apenas por compatibilidade
TLS1_0 = 1
TLS1_1 = 0
TLS1_2 = 0

            Ao subir a aplicação encontramos a configuração co a ausência da versão TLS1.2 indicada na chave TLS1:

            [INFO ][SSL] [tSSLSocketAPI][Initialize] starting handshake ..
            [INFO ][SSL] [tSSLSocketAPI] Using SSL/TLS protocol.
            [INFO ][SSL] SSL CIPHERS ALL
            [INFO ][SSL] [tSSLSocketAPI][Initialize] Bugs (0)
            [INFO ][SSL] [tSSLSocketAPI][Initialize] SSL2 (1), SSL3 (1), TLS1.0 (1), TLS1.1 (0), TLS1.2 (0)
            [INFO ][SSL] [tSSLSocketAPI][Initialize] State (1)
            [INFO ][SSL] [tSSLSocketAPI][Initialize] Setting Certificates

            3.4. TryProtocol deprecated

            Nâo há mais funcionalidade para a chave TryProtocols. Com a refatoração de alguns métodos de conexão a chave TryProtocols deixou de indicar explicitamente a necessidade de retentativas de conexões em outras versões do protocolo SSL/TLS. Isso implica em um custo menor no overhead gasto no estabelecimento de conexões, pois a própria implementação do protocolo negociará a versão de maior grau de segurança para conexão.

            3.5. WSDLManager não Contemplado nas Alterações

            Esta implementação não envolve a classe WSDLManager, que contém implementação própria do protocolo, restringindo ao uso do AppServer como servidor de conexão (WEBEX, HTTTPS) e as funções de acesso HTTPSGet, HTTPSPost.


            Disponibilidade

            O estudo foi realizado utilizando a versão do Application Server 13.1.3.25 e 13.2.3.25. As alterações propostas somente estarão disponíveis a partir da versão do Application Server 13.1.3.26 e 13.2.3.26.



            Utilizando SSL – Secure Socket Layer

            SSL - Secure Sockets Layer e TLS - Transport Layer Security (TLS) são protocolos criptográficos que provê segurança de comunicação na intenet.

             

            Abrangência
            ERP 10 e 11



            SSL é um protocolo de comunicação que aplica uma camada de segurança que é comumente utilizada para codificar os dados trafegados entre um ponto de comunicação a outro (Exemplo: Browser e WebSite). Desta forma, através do processo de criptografia dos dados, é possível prevenir que os dados trafegados possam ser interpretados ou mesmo alterados no seu percurso, garantindo que as informações sigilosas não possam ser vistas ou interpretadas.

            Para ser capaz de criar uma conexão SSL, um servidor requer um certificado SSL. Ao optar por ativar o SSL no servidor, é necessário criar duas chaves criptográficas, sendo uma chave privada e uma pública. Desta mesma maneira, é preciso que um Client possua um certificado SSL, que seja relacionado ao certificado no Server no qual será conectado. Este relacionamento/conexão ao Server e de verificação do certificado Client e Server é denominado handshake.

             

            Handshake

            Handshake é o processo em que duas máquinas afirmam uma a outra que a reconheceu e está pronta pra iniciar a comunicação.

            Observe, a seguir, um exemplo genérico de handshake realizado entre uma conexão TCP client/server utilizando SSL. 

            Fonte: http://en.wikipedia.org/wiki/Secure_Sockets_Layer#How_it_works

             

            Utilizando SSL em contexto WEB

            A utilização do SSL em protocolo HTTP - HyperText Transfer Protocol, é definido como HTTPS - HyperText Transfer Protocol Secure. HTTPS é uma implementação do protocolo HTTP sobre uma camada SSL ou TLS. Essa camada adicional, permite que os dados sejam transmitidos através de uma conexão criptografada e que se verifique a autenticidade do server e do client, através de certificados digitais.

            Importante
            A porta TCP usada, por norma, para o protocolo HTTPS é a 443.

             

            O protocolo HTTPS é utilizado, em regra, quando se deseja evitar que a informação transmitida entre o client e o server seja visualizada por terceiros, como, por exemplo, em compras on-line.

             

            Verificando a utilização do SSL

            Quando um visitante de um Website se conecta a um servidor que está utilizando o protocolo SSL, observe na barra de endereço, que o protocolo passa a ser https:// (no lugar de http:// padrão).

            Além disso, é possível verificar na barra de status, um cadeado que demonstra a certificação da página segura (SSL).

            Exemplos

            Internet Explorer ®

             

            Mozilla Firefox ®

             

            Certificado digital SSL

            Um certificado digital é um arquivo de computador que contém um conjunto de informações referente a entidade para o qual o certificado foi emitido (seja uma empresa, pessoa física ou computador) mais a chave pública referente a chave privada que acredita-se ser de posse unicamente especificada no certificado.

            Um certificado digital normalmente é usado para ligar uma entidade a uma chave pública. Para garantir digitalmente, no caso de uma infraestrutura de chaves públicas (ICP), o certificado é assinado pela Autoridade Certificadora que emitiu e, no caso de um modelo de Teia de Confiança (Web of trust), como o PGP, o certificado é assinado pela própria entidade e assinado por outros que dizem confiar naquela entidade. Em ambos os casos, as assinaturas contidas em um certificado são atestamentos realizados por uma entidade que diz confiar nos dados contidos naquele certificado.

            A troca de chaves simétricas entre usuários para comunicação segura tornou-se impraticável, a criptografia de chaves públicas provê um meio de solucionar este problema.

            Exemplo

            Alice deseja que outras pessoas tenham a capacidade de enviar-lhe mensagens secretas, tudo que ela precisa fazer é publicar a sua chave pública. Desta forma, qualquer pessoa que possua a chave pública de Alice poderá enviar-lhe informações secretas. No entanto, infelizmente, Davi também pode publicar uma chave pública (para a qual Davi sabe a chave privada relacionada) alegando ser a chave pública de Alice e assim tendo a capacidade de decifrar as mensagens secretas destinadas a Alice, mas que foram cifradas pela chave pública de Davi. Mas se Alice possuir um certificado digital com a sua chave pública e este certificado for assinado digitalmente por João, qualquer pessoa que confie em João poderá sentir-se confortável em confiar no certificado de Alice. Em uma ICP, João será uma AC (Autoridade Certificadora), a qual tem a confiança de todos os participantes daquela ICP.

            Um certificado pode ser revogado se for descoberto que a sua chave privada relacionada foi comprometida ou se o seu relacionamento (entre uma entidade e a sua chave pública) embutido no certificado estiver incorreto ou foi alterado; Isto poderá ocorrer, por exemplo, se uma pessoa mudar de nome ou CPF. Uma revogação não é comum, mas a possibilidade da ocorrência significa que quando um certificado é confiável, o usuário deverá sempre verificar a sua validade.
            Isto pode ser feito, comparando o certificado com uma lista de certificados revogados (LCR). Seu objetivo é mostrar todos os certificados revogados ou cancelados no âmbito daquela AC (Autoridade Certificadora).

            Garantir que a lista está correta e atualizada é a parte mais importante em uma ICP centralizada, o que as vezes não é feito corretamente. Para a LCR ser efetiva, precisa estar disponível o tempo todo para qualquer um que precisar e ser atualizada frequentemente. A outra maneira de conferir a validade de certificado, é fazer uma consulta a AC (Autoridade Certificadora) usando o Online Certificate Status Protocol (OCSP) para saber o estado de um certificado específico.

             

            O que é uma Autoridade Certificadora (CA)

            As Certification Authority ou Autoridade Certificadora (CA), são empresas que realizam a emissão dos certificados seguros SSL. As autoridades certificadoras são responsáveis por validar a identidade de um Website.
            O que mais se aproxima de uma entidade normatizadora das autoridades certificadoras, é o Webtrust Compliancy Program administrado pela AICPA/CICA. A maioria das CA´s obedecem aos critério da Webtrust.

             

            Referência, no servidor, para associação ao certificado

            O certificado fica associado ao nome da máquina (CommonName). Então, para registrar o certificado, é necessário definir a URL que será utilizada.

            Exemplo: www.seunome.com.br ou seguro.seunome.com.br

            Desta forma, o certificado ficará válido somente no endereço definido.

             

            Realizando testes com certificado sem pagamento

            Quase todos os fornecedores de certificados oferecem uma versão trial do certificado, permitindo instalá-la em seu servidor e testá-la à vontade,
            sem que haja necessidade de pagar por isso. É possível adquirir uma versão trial, através do site de certificados.


            Utilizando OpenSSL

            Este guia utilizará como base para geração de certificados, conversão de formatos de certificado digital, entre outras operações o projeto OpenSSL (http://www.openssl.org/).

            A versão Win32 do aplicativo é encontrada no site http://www.slproweb.com/products/Win32OpenSSL.html

            Para entender melhor alguns dos comandos utilizados do OpenSSL, consulte o site http://www.openssl.org/docs/apps/openssl.html

             

             

            Veja também

            Configuração SSL no TOTVS | Aplication Server

             

              ↑ início

            6. Integrações

            Garantir a segurança das informações nas comunicações, interna ou externa, por meio eletrônico ou físico.

            É de responsabilidade do cliente garantir que a comunicação, entre os componentes de instalação, seja feita de maneira segura. Garantindo que as informações, trafegadas entre as pontas, não sejam interceptada ou sofra ataques.

            A TOTVS apresenta algumas sugestões/orientações para segurança dos dados:

            • Mapear e avaliar as integrações de informações realizadas nos processos da empresa;
            • Evitar integrações a nível de banco de dados, quando não for possível, sugerimos o uso de criptografia em ambos os bancos;
            • Restringir acesso a diretórios e arquivos;
            • Para rotinas que geram arquivos em formatos txt, xml, html, csv e outros, sugerimos o descarte após o uso ou transferência para local seguro;
            • Inserir senhas em arquivos enviados por e-mail;
            • Utilizar integrações por meio de APIs contendo protocolos seguros.
            Impacto no produto


              Conceito

              Uma API (acrônimo de Application Programming Interface ou Interface de Programação de Aplicação em português) é um conjunto de rotinas e padrões estabelecidos por um software para a utilização de seus recursos por aplicativos que não pretendem envolver-se em detalhes da implementação do software, mas apenas usar seus serviços. De modo geral, uma API é composta por uma série de funções acessíveis somente por programação e que permitem utilizar características do software menos evidentes ao usuário tradicional.

              No desenvolvimento do produto Logix uma API antigamente chamava-se RNL acrônimo de Regra de Negócio Logix.

              Desenvolvimento

              Para o correto desenvolvimento é preciso ter em mente alguns cuidados que devem ser sempre considerados na construção de uma API:

              • Nunca desenvolva ou solicite qualquer interação com o usuário, seja ela através de telas, mensagens ou perguntas;
              • Simplifique suas funções, não é uma boa prática construir uma função "faz tudo", separe sempre sua lógica em diversas funções que possam ser executadas de formas distintas;
              • Evite que suas funções dependam do produto, lembre-se que elas poderão ser executadas através de outros produtos ou serviços; e
              • Sempre desenvolva visando a solução de único objetivo de negócio. Uma API para manutenção de pedidos não pode conter manutenção de empresas, por exemplo.

              Nos próximos itens deste documento, serão detalhadas as técnicas que devem ser seguidas na construção do código fonte da API.

              Para específicos

              Utilize sempre como base para a criação de uma API TOTVS o Guia de Implementação de API TOTVS, disponível em: Guia Pocket para construção de API's

              Índice

              Conceito

              Uma API (acrônimo de Application Programming Interface ou Interface de Programação de Aplicação em português) é um conjunto de rotinas e padrões estabelecidos por um software para a utilização de seus recursos por aplicativos que não pretendem envolver-se em detalhes da implementação do software, mas apenas usar seus serviços. De modo geral, uma API é composta por uma série de funções acessíveis somente por programação e que permitem utilizar características do software menos evidentes ao usuário tradicional.

              No desenvolvimento do produto Logix uma API antigamente chamava-se RNL acrônimo de Regra de Negócio Logix.

              Desenvolvimento

              Para o correto desenvolvimento é preciso ter em mente alguns cuidados que devem ser sempre considerados na construção de uma API:

              • Nunca desenvolva ou solicite qualquer interação com o usuário, seja ela através de telas, mensagens ou perguntas;
              • Simplifique suas funções, não é uma boa prática construir uma função "faz tudo", separe sempre sua lógica em diversas funções que possam ser executadas de formas distintas;
              • Evite que suas funções dependam do produto, lembre-se que elas poderão ser executadas através de outros produtos ou serviços; e
              • Sempre desenvolva visando a solução de único objetivo de negócio. Uma API para manutenção de pedidos não pode conter manutenção de empresas, por exemplo.

              Nos próximos itens deste documento, serão detalhadas as técnicas que devem ser seguidas na construção do código fonte da API.

              Clique AQUI para obter o código 4GL base de uma API para desenvolvimento e complemente o código conforme a necessidade da sua API.

              Para específicos

              Utilize sempre como base para a criação de uma API TOTVS o Guia de Implementação de API TOTVS, disponível em: http://tdn.totvs.com/x/nDUxE

              01. Introdução


                   O desenvolvimento de APIs permite a exposição e o consumo de dados para integração (front-end, portais, customizações, etc) com o back-end do produto Logix, de maneira segura e padronizada.

                   A estrutura de integração de APIs Logix suporta o envio de requisições no estilo de arquitetura REST com o desenvolvimento da regra de negócio em 4GL e está disponível para utilização conforme apresentado no quadro abaixo:


              Matriz de Evolução

              Versão / Release Funcionalidade
              12.1.22

              Requisições através dos verbos GET / POST / PUT / DELETE utilizando o contexto /restlogix

              Classe utilitária para tratamento das respostas da requisição (response) em 4GL.
              12.1.24

              Requisições através dos verbos GET / POST / PUT / DELETE utilizando o contexto /api

              Classe utilitária para tratamento das respostas da requisição (response) em 4GL.

              O contexto /restlogix está em processo de depreciação.


              02. Formato URL


                    O Guia de Implementação de API TOTVS define que o formato das URIs dos endpoints devem conter o nome do produto, o módulo, a versão da API e o recurso alvo da funcionalidade em questão. Tomando como exemplo o endpoint de integração do recurso de "Dimensões" do módulo de "WMS" do produto "Logix", a URI básica deste serviço deve ser: /api/wms/v1/dimensoes


              A URL definida pelo Padrão de API TOTVS segue o seguinte formato:

              /api/<módulo>/<versão API>/<recurso>/

              Informações que forem passadas após o recurso, serão tratadas como parâmetros PATH.


              03. Serviços 4GL

                   Para "publicar" a funcionalidade 4GL basta criar o programa (.4gl) com o seguinte caminho: <módulo>/api/<versão API>/<recurso>.4gl. 

                   A sub-pasta "api" passa a concentrar todas as funcionalidades de integração dos módulos existentes. Outros caminhos e parâmetros podem ser adicionados a URL, mas sempre de acordo com o Guia de Implementação de APIs.


              Importante

              Os programas 4GL disponibilizados, deverão seguir o padrão de localização abaixo:

              Exemplos:

              Objeto de Negócio Função de roteamento
              \suprimentos\obrigacoes_fiscais\api\v1\transportadoras.4gl obf_v1_transportadoras
              \suprimentos\suprimentos\api\v1\estoque.4gl sup_v1_estoque
              \adm_producao\manufatura\api\v1\apontamento_horas.4gl man_v1_apontamento_horas


                   Dentro do código fonte 4GL a definição da função principal (roteadora) é de fundamental importância, pois é ela que será primeiramente chamada e que definirá como será a execução das outras funções com base na requisição solicitada. Segue abaixo um exemplo de definição:


              04. Exemplo de desenvolvimento das funções em 4GL


              NOMES DAS FUNÇÕES

              Exemplo de definição de funções e como será realizada a requisição WEB de execução destas funções:

              Função Requisição

              FUNCTION

              obf_v1_transportadoras()

              GET/POST/PUT/DELETE

              /api/obf/v1/transportadoras

              FUNCTION

              sup_v1_estoque()

              GET/POST/PUT/DELETE

              /api/sup/v1/estoque

              FUNCTION

              man_v1_apontamento_horas()

              GET/POST/PUT/DELETE

              /api/man/v1/apontamento_horas

              APIS Específicas de clientes (Fábrica de Software)


              Para funções de APIs específicas mantidas pela Fábrica de Software, conforme citado na nota IMPORTANTE no final do tópico 03. Serviços 4GL,  a sigla do módulo indicada no início das funções é acrescida de "e".

              Exemplos:  

                 obfe_v1_transportadoras()

                 supe_v1_estoque()

                 mane_v1_apontamento_horas()


              Quais funções devem sempre existir e respeitar padronização de nomenclatura:

              • Função principal roteadora. Esta função não possui parâmetros e tem como objetivo a definição das rotas.
              • Funções definidas na função roteadora para cada uma das rotas. Estas funções devem ter sempre a definição de 1 parâmetro do tipo VARCHAR(10) que será a referência do objeto de classe LJsonObject que é enviado no ato de toda requisição. Também sempre devem ter um retorno no formato JSON que será o retorno da requisição, utilizando para isso a classe LRestLogixResponse. Ambas classes estão detalhadas em Classes Utilitárias.


              EXEMPLO DE IMPLEMENTAÇÃO

              DATABASE Logix

{#
 #Função roteadora principal que será executada pelo Logix REST quando feito 
 #uma requisição que combine com o módulo, a versão e o recurso da função.
 #}
#---------------------------#
 FUNCTION wms_v1_dimensoes()
#---------------------------#
{DEFINIÇÃO DAS ROTAS}

    #Inicia a técnica para definição das rotas de execução das funções conforme a requisição recebida.
 	CALL _ADVPL_create_rest_logix_routes()
 	
    #Definição de rota onde toda requisição de método GET, que contenha o filtro a seguir,
    #será direcionada para função wms_v1_dimensoes_get_normal().
    #FILTRO:
    # - Serão capturadas todas as requisições que possuírem um parâmetro Path "/normal" 
    #   e um parâmetro Query "fields" com qualquer conteúdo (*). 
 	CALL _ADVPL_add_rest_logix_routes("GET",                      #--# Método #--#
 	                                  "/normal/*/",               #--# Path Param a ser filtrado #--#
 	                                  "fields=*",                 #--# QueryParam a ser filtrado #--#
 	                                  "wms_v1_dimensoes_get_normal")  #--# Função a ser executada #--#
 	 
    #Definição de outra rota, onde toda requisição de método GET, que contenha o filtro a seguir,
    #será direcionada para função wms_v1_dimensoes_get_ordenado().
    #FILTRO:
    # - Serão capturadas todas requisições que contenha qualquer parâmetro Path ("/*"  indica "Todos Paths" ou "nenhum") 
    #   e um parâmetro Query "order" com valor "dimensao"
    CALL _ADVPL_add_rest_logix_routes("GET",                           
 	                                  "/*",                            
 	                                  "order=dimensao",                
 	                                  "wms_v1_dimensoes_get_ordenado")  
 	
    #Definição de outra rota, onde todas as requisições de método GET, que possuírem quaisquer parâmetros 
    #(Query e/ou Path) informados, serão direcionadas para a função wms_v1_dimensoes_get().
 	CALL _ADVPL_add_rest_logix_routes("GET",                          
 	                                  "/*",                           
 	                                  "",                             
 	                                  "wms_v1_dimensoes_get")        
 	                             
    #Definição de rota onde todas as requisições de método POST, que possuírem quaisquer parâmetros (Query e/ou Path) informados, 
    #serão direcionadas para a função wms_v1_dimensoes_post().
	CALL _ADVPL_add_rest_logix_routes("POST",                        
 	                                  "/*",                         
 	                                  "",                           
 	                                  "wms_v1_dimensoes_post")       
 	                                  
    #Definição de rota onde todas as requisições de método PUT (update), que possuírem quaisquer parâmetros (Query e/ou Path) informados, 
    #serão direcionadas para a função wms_v1_dimensoes_put().
 	CALL _ADVPL_add_rest_logix_routes("PUT",                           
 	                                  "/*",                            
 	                                  "",                             
 	                                  "wms_v1_dimensoes_put")  
 	                                  
    #Definição de rota onde todas as requisições de método DELETE, que possuírem quaisquer parâmetros (Query e/ou Path) informados, 
    #serão direcionadas para a função wms_v1_dimensoes_delete().
    CALL _ADVPL_add_rest_logix_routes("DELETE",                       
 	                                  "/*",                          
 	                                  "",                            
 	                                  "wms_v1_dimensoes_delete")   
END FUNCTION

#------------------------------------------------------#
 FUNCTION wms_v1_dimensoes_get_normal(l_json_reference)
#------------------------------------------------------#
#FUNÇÃO GET COM PATH PARAM "NORMAL" ADICIONADA COMO ROTA NA FUNÇÃO wms_v1_dimensoes()

	DEFINE l_json_reference VARCHAR(10)
	DEFINE l_json VARCHAR(1000)
	
	.
	.
	.

	RETURN l_json
END FUNCTION


#-------------------------------------------------------#
 FUNCTION wms_v1_dimensoes_get_ordenado(l_json_reference)
#-------------------------------------------------------#
#FUNÇÃO GET COM PATH PARAM "ORDENADO" ADICIONADA COMO ROTA NA FUNÇÃO wms_v1_dimensoes()

	DEFINE l_json_reference VARCHAR(10)
	DEFINE l_json VARCHAR(1000)
	
	.
	.
	.

	RETURN l_json
END FUNCTION

              IMPORTANTE

              Para PATH com valor obrigatório informe ?* (interrogação seguido de asterisco), que determina que o PATH tem ao menos 1 caracter qualquer (?), seguido de 0 ou mais caracteres (*).

              Exemplo: "/normal/?*/", #--# Path Param obrigatório a ser filtrado #--#

              OBSERVAÇÕES

              Algumas considerações sobre o uso de roteamento através da função _ADVPL_add_rest_logix_routes():

              • Os roteamentos devem ser definidos sempre do mais específico (detalhado) para o mais genérico (simples).
              • O Logix REST utiliza a função Match() do ADVPL, que basicamente permite o uso do sinal "?" (interrogação) como coringa para uma determina um único caracter obrigatório e o sinal "*" (asterisco) para um conjunto de caracteres variáveis (zero ou mais caracteres). Neste caso, quando houver necessidade de ter ao menos 1 caracter obrigatório, deve-se informar "?*" que determinará "1 ou mais caracteres" e quando informar "*" (apenas asterisco) determinará "0 ou mais caracteres". Para mais detalhes acesse a documentação da função Match().
              • Podem ser definidos um ou mais parâmetros de pesquisa utilizando a "," (vírgula) como separador e a pesquisa sempre será realizada utilizando o operador AND.
                Exemplo:
                CALL _ADVPL_add_rest_logix_routes("GET",                           
 	                              "/*",                            
 	                              "order=dimensao,cliente=*",                
 	                              "wms_v1_get_dimensoes_ordenado")

                Veja que o parâmetro QUERY foi repassado como "order=dimensao,cliente=*" onde existem 2 filtros separados por uma vírgula, sendo:

              FILTRO 1: order=dimensao

              FILTRO 2: cliente=*

              • Atente aos valores repassados como QUERY e PATH pois são processados como CaseSensitve.


              05. Formato Mensagem JSON

                    A variável de referência de um objeto LJSONOBJECT, recebida pela requisição como parâmetro na função 4GL definida na rota conterá informações completas da requisição, desde informações do HEADER, QUERY PARAMs, PATH PARAMs e o próprio PAYLOAD.

                    Através desta mensagem, o desenvolvedor poderá efetuar os devidos filtros e lógicas necessárias. 


              EXEMPLO DE MENSAGEM JSON

              { 
    uri: valor,
	method: GET,
    headers: {},
	pathParams: [ "param1", "param2" ],
	queryParams: { query1: valor1, query2: valor1},
	payload: {}
}

              06. Classes Utilitárias 

                    Com o objetivo de facilitar a manipulação dos objetos JsonObject recebidos e enviados pela API 4GL, foram desenvolvidas algumas classes de utilitários:

              LJSONObject

              Permite manipular o JSON recebido como parâmetro pela função. 

              Acesse a documentação referente ao componente Logix LJSONOBJECT para saber mais detalhes de como manipular informações recebidas num formato JSON.


              LRestLogixResponse 

              Trata a criação do JSON de response da requisição.

              Acesse a documentação referente ao componente LOGIX LRESTLOGIXRESPONSE para saber mais detalhes a respeito das propriedades SET e GET disponíveis.


              07. Exemplo de montagem do JSON de retorno


              EXEMPLO MONTAGEM DO JSON DE RETORNO DA REQUISIÇÃO

              Criação de Response 
              #-----------------------------------------------#
 FUNCTION wms_v1_dimensoes_get(l_json_reference)
#-----------------------------------------------#
	DEFINE l_json_reference VARCHAR(10)
    DEFINE l_logix_response VARCHAR(10)
	DEFINE l_json CHAR(1000)
	
    #--# Utilização do método SERIALIZE da classe LJSONOBJECT  #--#
	LET l_json = _ADVPL_get_property(l_json_reference,"SERIALIZE")
	
	#--# Criação da resposta padronizada utilizando a classe LRestLogixResponse  #--#
	LET l_logix_response = _ADVPL_create_component(NULL,"LRestLogixResponse")
    CALL _ADVPL_set_property(l_logix_response,"PAYLOAD",l_json,"payload")

	#--# Propriedades opcionais (mensagem de erro, detalhamento do erro, código do erro #--#
    CALL _ADVPL_set_property(l_logix_response,"MESSAGE","Mensagem de erro","Detalhamento do erro", "10")
	#--# Definição do status de retorno da requisição
    CALL _ADVPL_set_property(l_logix_response,"STATUS",'200')

	#--# Opcional, utilizada quando o conteúdo de retorno for um JSONArray #--#
	CALL _ADVPL_set_property(l_logix_response,"HAS_NEXT",TRUE)
    
    #Retorno do conteúdo do componente LRestLogixResponse no formato JSON
	RETURN _ADVPL_get_property(l_logix_response,"GENERATE")
END FUNCTION


              08. Exemplo de leitura dos dados da requisição


              EXEMPLO DE LEITURA DOS DADOS ENVIADOS NO JSON DA REQUISIÇÃO

              A leitura dos dados do JSON da requisição é realizada utilizando a função _ADVPL_get_property(l_json_reference, "VALUE",<campo>)

              Carregando um Array de Record 
                 DEFINE l_json_data          CHAR(30000)
   DEFINE l_json_reference     VARCHAR(10)    
   DEFINE l_length_ajusts      SMALLINT
   DEFINE l_status             SMALLINT
   DEFINE l_ind                SMALLINT 
   
   DEFINE ma_ajust_bxa_adt_integ  ARRAY[500] OF RECORD
	                                               cod_tip_val      LIKE ad_valores.cod_tip_val,
	                                               valor            LIKE ad_valores.valor,
	                                               num_ad_nf_orig   LIKE adiant.num_ad_nf_orig,
	                                               ser_nf           LIKE adiant.ser_nf,
	                                               ssr_nf           LIKE adiant.ssr_nf,
	                                               cod_fornecedor   LIKE adiant.cod_fornecedor,
	                                               dat_mov          LIKE mov_adiant.dat_mov      
	                                            END RECORD                  
                                                                
    #Esta informação da variável l_json_data abaixo é apenas um exemplo do conteúdo JSON que já é recebido pelas requisições REST.
    LET l_json_data = 
   '{
   		"payload": {
   		    "ajustBxaAdtInteg": [
	   		    {
	   		       "codTipVal": "1",
	   		       "valor": 1000,
	   		       "numAdNfOrig": 123456,
	   		       "serNf": "AD",
	   		       "ssrNF": "A",
	   		       "codFornecedor": "12",
	   		       "datMov": "10/10/2019"
	   		    },
	   		    {
	   		       "codTipVal": "2",
	   		       "valor": 3000,
	   		       "numAdNfOrig": 654321,
	   		       "serNf": "AF",
	   		       "ssrNF": "B",
	   		       "codFornecedor": "13",
	   		       "datMov": "01/12/2018"
	   		    },
	   		    {
	   		       "codTipVal": "3",
	   		       "valor": 2000,
	   		       "numAdNfOrig": 555555,
	   		       "serNf": "AJ",
	   		       "ssrNF": "C",
	   		       "codFornecedor": "14",
	   		       "datMov": "31/10/2019"
	   		    }
   		    ]
   		}
   }'
   
   LET l_json_reference = _ADVPL_create_component(NULL, "LJSONOBJECT")
   LET l_status         = _ADVPL_get_property(l_json_reference,"ACTIVATE",l_json_data CLIPPED)
   
   LET l_length_ajusts = _ADVPL_get_property(l_json_reference,"LENGTH","payload/ajustBxaAdtInteg")

   #Leitura dos itens da lista "ajustBxaAdtInteg" existentes no JSON da requisição   
   FOR l_ind = 1 TO l_length_ajusts
       LET ma_ajust_bxa_adt_integ[l_ind].cod_tip_val    = _ADVPL_get_property(l_json_reference, "VALUE", "payload/ajustBxaAdtInteg["||l_ind||"]/codTipVal")
       LET ma_ajust_bxa_adt_integ[l_ind].valor          = _ADVPL_get_property(l_json_reference, "VALUE", "payload/ajustBxaAdtInteg["||l_ind||"]/valor")
       LET ma_ajust_bxa_adt_integ[l_ind].num_ad_nf_orig = _ADVPL_get_property(l_json_reference, "VALUE", "payload/ajustBxaAdtInteg["||l_ind||"]/numAdNfOrig")
       LET ma_ajust_bxa_adt_integ[l_ind].ser_nf         = _ADVPL_get_property(l_json_reference, "VALUE", "payload/ajustBxaAdtInteg["||l_ind||"]/serNf")
       LET ma_ajust_bxa_adt_integ[l_ind].ssr_nf         = _ADVPL_get_property(l_json_reference, "VALUE", "payload/ajustBxaAdtInteg["||l_ind||"]/ssrNF")
       LET ma_ajust_bxa_adt_integ[l_ind].cod_fornecedor = _ADVPL_get_property(l_json_reference, "VALUE", "payload/ajustBxaAdtInteg["||l_ind||"]/codFornecedor")
       LET ma_ajust_bxa_adt_integ[l_ind].dat_mov        = _ADVPL_get_property(l_json_reference, "VALUE", "payload/ajustBxaAdtInteg["||l_ind||"]/datMov")
       
       CALL CONOUT("------------------- Exibindo os valores --------------------")
       CALL CONOUT(ma_ajust_bxa_adt_integ[l_ind].cod_tip_val)
       CALL CONOUT(ma_ajust_bxa_adt_integ[l_ind].valor)
       CALL CONOUT(ma_ajust_bxa_adt_integ[l_ind].num_ad_nf_orig)
       CALL CONOUT(ma_ajust_bxa_adt_integ[l_ind].ser_nf)
       CALL CONOUT(ma_ajust_bxa_adt_integ[l_ind].ssr_nf)
       CALL CONOUT(ma_ajust_bxa_adt_integ[l_ind].cod_fornecedor)
       CALL CONOUT(ma_ajust_bxa_adt_integ[l_ind].dat_mov)
   
   END FOR


              09. Exemplo de leitura dos filtros da requisição (QueryParam e PathParam)


              EXEMPLO DA LEITURA DOS FILTROS QueryParam E PathParam ENVIADOS NO JSON DA REQUISIÇÃO

              Carregar QueryParam e PathParam 
              #--------------------------------------------------#
 FUNCTION vdp_v1_clientes_nacionais(l_json_reference)
#--------------------------------------------------#
    DEFINE l_json_reference VARCHAR(10)
    DEFINE l_logix_response VARCHAR(10)
	DEFINE l_query_param CHAR(200)
	DEFINE l_path_param  CHAR(200)
	DEFINE l_json_retorno CHAR(1000)
	
    # Carrega o valor da primeira entrada do Query Param #--# 
    # Exemplo de QueryParams ?order=dimensao&cliente=1234: '[["order","dimensao"],["cliente","1234"]]'
    # No exemplo abaixo, a busca acontece no primeiro QueryParam (order) buscando o nome dele (order) 
	LET l_query_param = _ADVPL_get_property(l_json_reference,"VALUE","queryparams[1][1]") 

    # Neste exemplo, a busca acontece no primeiro QueryParam (order) buscando o valor dele (dimensao) 
	LET l_query_param = _ADVPL_get_property(l_json_reference,"VALUE","queryparams[1][2]") 

    # No exemplo abaixo, a busca acontece no segundo QueryParam (cliente) buscando o nome dele (cliente) 
	LET l_query_param = _ADVPL_get_property(l_json_reference,"VALUE","queryparams[2][1]") 

    # Neste exemplo, a busca acontece no primeiro QueryParam (cliente) buscando o valor dele (1234) 
	LET l_query_param = _ADVPL_get_property(l_json_reference,"VALUE","queryparams[2][2]")
	
	# Carrega o primeiro Path Param 
    # Exemplo: '{"pathparams":["path1","path2"]}'
	LET l_path_param = _ADVPL_get_property(l_json_reference,"VALUE","pathparams[1]") 
	
	LET l_json_retorno = '{"queryParam":"',LOG_alltrim(l_query_param),'","pathParam":"',LOG_alltrim(l_path_param),'"}'
	
	# Executar a regra de negócio neste ponto 
	LET l_logix_response = _ADVPL_create_component(NULL,"LRestLogixResponse")
    CALL _ADVPL_set_property(l_logix_response,"PAYLOAD",l_json_retorno,"payload")
    CALL _ADVPL_set_property(l_logix_response,"STATUS",'200')
    
	RETURN _ADVPL_get_property(l_logix_response,"GENERATE")
END FUNCTION




              INTRODUÇÃO


              O Mingle é uma plataforma disponibilizada como serviço para a sustentação de aplicativos (atualmente móveis) resolvendo três principais necessidades dos clientes: Autenticação, API Gateway e Métrica, sem que os produtos tenham que expor suas APIs diretamente para quem irá consumi-las, deixando o controle dessa exposição para o próprio Mingle.

              Um dos pontos importantes é que o Mingle não realiza diretamente nenhuma autenticação.


              FLUXO DE CONSUMO DE LICENÇAS A PARTIR DE APPs TOTVS a partir da plataforma Mingle



              Como funciona então a autenticação de um usuário do ERP Logix a partir de um APP (móbile ou WEB) utilizando a plataforma Mingle como Gateway?

              1. O Mingle, através das informações recuperadas do cadastro do aplicativo, sabe qual o driver utilizar para realizar a autenticação e em qual host deve executá-la.
              2. O host após receber as credenciais do Mingle, autentica (ou não) o usuário e dependendo do seu tipo de autenticação pode devolver ao Mingle mecanismos para renovar essa autenticação, o Mingle irá tratar de forma transparente para o aplicativo essa renovação.
              3. O Mingle irá retornar ao app a resposta enviada pelo host sobre o resultado da autenticação, em caso de sucesso, também será enviado um tokenJWT para garantir a integridade das mensagens trocadas.
              4. Com o usuário autenticado o app poderá realizar as requisições (também através do Mingle) no host do respectivo usuário.


              O Fluxo é o mesmo para ambiente móbile ou WEB?


              O fluxo é praticamente o mesmo, considerando que toda as requisições de APIs REST tem sua comunicação realizada com o Mingle.


              Para exemplificar abaixo está a imagem correspondente ao fluxo Móbile. 



              O Mingle tem apenas um ambiente único de acesso? Como posso realizar testes e homologações?


              O Mingle possui atualmente 3 ambientes disponíveis sendo:


              Desenvolvimento

              https://dev-mingle.totvs.com.br

              Homologação

              https://hom-mingle.totvs.com.br

              Produção (Ambiente oficial)

              https://mingle.totvs.com.br

                   

              Como inicio os testes de um portal o APP utilizando o Mingle como Gateway?

              Como pré-requisito para implementar na plataforma do Mingle, a aplicação deve estar cadastrada na plataforma Mingle. 

              Leia um pouco da documentação da ferramenta Mingle disponível nos links disponíveis no tópico DOCUMENTAÇÕES COMPLEMENTARES.

              Para cadastro de ALIAS na plataforma Mingle para desenvolvimento Logix clique AQUI. Lembre-se de acessar o ambiente MINGLE confome a sua necessidade (Desenvolvimento, Homologação ou Produção).

              Cada ALIAS no Mingle, no caso do Logix será vinculado ao IP e porta do serviço REST de um AppServer Logix, pois é desta forma que o Mingle irá enviar as requisições REST de acesso ao ERP Logix.

              Em caso de dúividas procure apoio com integrantes da equipe responsável pelo desenvolvimento da plataforma Mingle.


              Como faço para alternar entre os ambientes do Mingle para execução no Logix?

              Basta configurar a chave MINGLE na seção do ambiente de execução do Logix no arquivo de configuração do AppServer.

              Para mais detalhes sobre como configurar esta chave acesse MINGLE [AMBIENTE].


              Como é feito o consumo da licença no Logix para execuções WEB Portais / API REST / WebServices?

              A partir do LOGIX 12.1.31 o consumo de licença no Logix será realizado conforme abaixo, respeitando cada forma de acesso:

              WEB Portais

              Será realizado consumo de licença TOTVS I (Slot 4093).

              API REST

              Será consumo por padrão a licença identificada na chave x-totvs-appcode que é enviada no header das requisições REST (via Mingle ou WSO2) e pode ter em seu conteúdo o código de Slot de licença do App Totvs que é identificado pelo elemento x-totvs-app na seção PAYLOAD da imagem abaixo que demonstra a decodificação de um token no formato JWT que é enviado na header da requisição pela chave x-totvs-appcode



              Caso o elemento x-totvs-appcode não seja identificado no JWTtoken, a licença padrão de portais será utilizada, ou seja, TOTVS I (Slot 4093).


              WebServices

              Será realizado consumo de licença TOTVS I (Slot 4093).


              Todas as integrações EAI, que também fazem uso da comunicação via WebServices (SOAP), estão isentas do consumo de licenças. Isso mesmo, TODAS as integrações EAI (mensagens recebidas ou enviadas) NÃO consumirão licenças no produto Logix.


              Como podemos identificar a licença consumida por um APP no desenvolvimento do Logix?

              Basta ativar o modo de DEBUG relacionado a licenças do Logix a partir do arquivo de profile (Chave LOGIX.license.debug=1) e acompanhar as mensagens geradas no arquivo de LOG do AppServer identificadas com a TAG [LICENSE]. Todas as mensagens são identificadas de forma que seja fácil a identificação do Slot de licença consumido no produto.


              CONCLUSÃO

              Todo o processo de consumo de licenças é controlado na camada de código Framework, sem a necessidade de desenvolvimento de código diferenciado para desenvolvimento de Portais ou APPs móbile no Logix, sendo o único requisito para estes casos é fazer uso das tecnologias de desenvolvimento padrões adotados pela Totvs para arquitetura de portais e APPs.


              DOCUMENTAÇÕES COMPLEMENTARES


              Conheça o Mingle

              Mingle: o gateway para produto legado da TOTVS

              Mingle x Logix! O Legado de um ERP externalizado em aplicações Web

              TOTVS Mingle API's Documentation

              Aplicativos TOTVS suportados








              No LOGIX, existem configurações a serem definidas no arquivo de configuração do TotvsAppserver (Arquivo Totvsappserver.ini) para executar e desenvolver métodos utilizando a arquitetura REST na tecnologia TotvsTec.


              A seguir será apresentado um exemplo de configuração do TotvsAppserver e algumas referências para outras documentações também disponíveis a respeito do mesmo assunto.


              Para mais detalhes a respeito de conceitos, configurações e testes utilizando arquitetura REST com TotvsTec clique AQUI (necessário solicitar permissão para equipe TotvsTec).



              Configurações no arquivo appserver.ini


              É necessário definir algumas seções no arquivo de configuração do Appserver e ajustar, quando necessário, os valores para o nome do ambiente (Chave ENVIRONMENT), porta (Chave PORT), quantidade de instâncias para execução no AppServer (Chave INSTANCES) e Chave URL para indicar o endereço em que as requisições REST serão atendidas.


              [ONSTART]
REFRESHRATE=30
JOBS=HTTPJOB 

[HTTPJOB]
MAIN=HTTP_START
ENVIRONMENT=logix12_ora  ;*** NOME DO AMBIENTE LOGIX, pode ser modificado

[HTTPV11]
ENABLE=1
SOCKETS=HTTPREST
TIMEOUT=600 

[HTTPREST]
PORT=8580   ;*** Porta utilizada na URI, pode ser modificada
URIS=URITESTE
SECURITY=0

[URITESTE]
URL=/   ;*** Endereço base pra atender as requisições REST. Exemplo: http://localhost:8580/api/vdp/v1/clientes
INSTANCES=2,2   ;*** Número de instâncias utilizadas para atender as requisições REST (quantidade inicial e máxima de instâncias)
ONSTART=LOGIXRESTSTART
ONCONNECT=LOGIXRESTCONNECT
ONEXIT=LOGIXRESTEXIT

              (aviso) ATENÇÃO! Fique atento ao utilizar o parâmetro de configuração com a chave Security=0, pois isso fará com que as integrações (APIs) não exijam autenticação e consequentemente dados do seu ambiente poderão ser consultados sem qualquer controle de autorização.

              (seleção) Neste caso é indicado que ative a autenticação REST conforme orientações no item Ativando autenticação REST a seguir.


              Com base na configuração acima, as requisições REST serão atendidas a partir da seguinte URL base:  http://localhost:8580/rest


              Ativando autenticação REST

              Para ativar o controle de autenticação nas requisições REST e passar a exigir que as requisições sejam executadas usando protocolo HTTPS, é necessário alguns procedimentos que estão descritos a seguir:


              Ative a chave SECURITY na seção HTTPREST:

              [HTTPREST]
PORT=8580   ;*** Porta utilizada na URI, pode ser modificada
URIS=URITESTE
SECURITY=1   ;*** Ativar a autenticação das requisições REST


              Ativando a chave SECURITY=1 precisará configurar também as seguintes chaves CERTIFICATE, KEY e PASSPHRASE na seção [HTTPREST], com os dado do certificado SSL.

              A partir da ativação da autenticação das requisições REST, na seção HEADER das requisições deverá constar o campo AUTHORIZATION contendo as informações de usuário e senha no formato BASE64.


              Exemplo:

              Supomos que para realizar a requisição de uma API REST do LOGIX seja necessário executar a URL de requisição abaixo:

              Informação

              Valor
              Método GET
              URL https://<servidor>:<porta_rest>/api/vdp/v1/states/SC 

              HEADER

              Authorization

              Basic Auth

              Username=[usuário logix] 

              Password=[senha usuário Logix]


              Para o exemplo acima, na seção Header da URL de requisição REST, deverá ser enviada a chave "Authorization":"BASIC XXXXXXXXXXXX", onde XXXXXXXXXXXX é a tupla usuario:senha do Logix convertidos em Base64.

              Exemplo: 


              Com isso a segurança na comunicação se dará principalmente pelo uso de certificados SSL que garantem a abertura da comunicação segura entre os dois pontos e também o uso da autenticação de um usuário logix válido.


                ↑ início

              7. Criptografia

              A criptografia garante a segurança da informação por meio de um conjunto de regras que visa codificar a informação de forma que só o emissor e o receptor consiga decifrá-la.

              A TOTVS aconselha que seus clientes utilizem o recurso "Criptografia de Dados Transparente (TDE)"  do SGBD do produto.

                ↑ início

              8. Anonimização

              A anonimização consiste na utilização de meios técnicos razoáveis e disponíveis no momento do tratamento, por meio dos quais um dado perde a possibilidade de associação, direta ou indireta, a um indivíduo.

              Impacto no produto

                CONTEÚDO

                1. Visão Geral
                2. Ações Principais
                  1. Revisar
                  2. Enviar
                  3. Status
                  4. Ver resultado da solicitação
                  5. Finalizar
                  6. Abandonar
                3. Outros recursos
                  1. Chat
                  2. Reenvio

                01. VISÃO GERAL

                A funcionalidade de Anonimização de Dados Pessoais permite que o Encarregado de Dados registre e administre solicitações de titulares que desejam exercer o direito ao esquecimento, previsto na LGPD.

                A forma de utilização é como da Consulta de Dados Pessoais, onde o Encarregado de Dados faz o registro da solicitação, e a partir disso, precisa executar uma série de ações até que possa encaminhar o resultado ao titular dos dados.

                Para abrir uma nova requisição, o Encarregado de Dados deve clicar no botão Solicitar.

                Sobre os dados solicitados em uma requisição, consultar a seção Campos de uma requisição desta página.

                As ações disponíveis para uma requisição de Anonimização de Dados Pessoais são:

                • Status
                • Chat
                • Revisar
                • Enviar
                • Ver resultado da solicitação
                • Finalizar
                • Abandonar
                • Reenviar

                02. AÇÕES PRINCIPAIS

                As ações aqui listadas dizem respeito ao ciclo de vida da requisição de Anonimização de Dados Pessoais.

                a. Revisar

                A anonimização de dados pessoais é um processo irreversível, que pode ter impacto significativo nos produtos integrados ao TOTVS Privacidade de Dados.

                Por este motivo, há o botão Revisar, cujo propósito é evidenciar os efeitos de uma solicitação de anonimização efetiva. As aplicações, ao receberem o pedido de verificação, simularão uma anonimização, mas sem modificar os dados. O resultado desta ação é um indicador de que os dados podem ser anonimizados, ou então, que há restrições que não permitem a anonimização efetiva de alguns ou de todos os dados pessoais encontrados.

                A ação está disponível para requisições com status Registrada.

                Quando o botão é acionado, a ferramenta emite uma notificação ao usuário e a requisição é encaminhada às aplicações integradas naquele momento. 

                O status passa para Em verificação, permanecendo nele até que todas as aplicações para as quais foi enviada a solicitação respondam.

                b.Enviar

                O botão Enviar está disponível para requisições com status Verificada e serve para encaminhar a requisição para as aplicações dos produtos habilitados no momento da ação.

                Esta ação indica para as aplicações que a anonimização deve ser realizada de fato. Entretanto, campos que possuam alguma restrição, já evidenciada no momento da verificação (ação Revisar), não serão anonimizados.

                Após o acionamento do botão, o usuário é solicitado a confirmar a ação. 

                Caso confirme, as aplicações que estiverem ativas no momento receberão a requisição, que terá seu status alterado para Em Processamento. 

                A requisição só mudará de status quando todas as aplicações para as quais o comando foi enviado responderem.

                c. Status

                Está disponível quando a requisição encontra-se no status Em Verificação ou Em Processamento.

                Ao acionar o botão, são listadas as aplicações para as quais a requisição foi enviada, e em qual situação se encontra.

                • Em Processamento: a aplicação ainda não emitiu uma resposta para a requisição.
                • Finalizada: a aplicação respondeu à requisição.

                Quanto todas as aplicações da lista responderem, o status da requisição muda para Verificada ou Processada e o botão de ação Status fica desabilitado.

                d. Ver resultado da solicitação

                O botão Ver resultado da solicitação é habilitado quando a requisição passa para o status Em Verificação ou Em Processamento. Com isso, é possível acompanhar os resultados a medida que as aplicações respondem às solicitações.

                O botão permanece disponível para todos os status subsequentes: Verificada, Processada, Finalizada e Abandonada.

                Ao acionar o botão, o Encarregado de Dados pode verificar os dados retornados pelas aplicações que responderam.

                Tanto para a etapa de verificação da anonimização, iniciada pelo botão Revisar, quando para a anonimização propriamente dita, disparada pelo botão Enviar, temos um mesmo layout de apresentação dos resultados:

                • Dados da requisição (número da requisição, data de registro, identificação do titular)
                • Mensagem informando o resultado geral
                • Exceções

                O exemplo abaixo corresponde a uma verificação para anonimização, onde houve restrições.

                Quando houver restrições a anonimização, em ambas as etapas, elas serão agrupadas por produto.

                Clicando em Ver Exceções, é redirecionado para mostrar os modelos de dados verificados e os dados pessoais associados, que possuem restrições.

                Os campos com exceção estão organizados por aplicação, é possível verificar o motivo da não anonimização (quando informado), a base legal e justificativa associada.

                Quando a anonimização ocorrer com sucesso em todas as aplicações do produto, sem restrições, será exibida apenas a mensagem Todos os seus dados pessoais foram anonimizados.

                Caso nenhuma das aplicações consiga realizar anonimização de dados com base nos identificadores informados, a tela terá a seguinte disposição:

                e. Finalizar

                O botão Finalizar encerra o ciclo da requisição. Está disponível para requisições com status Processada. 

                Quando acionado, a requisição passa para o status Finalizada e o botão é desabilitado.

                A ferramenta gera um e-mail de resposta para o endereço indicado na solicitação (campo E-mail para contato). Os dados serão encaminhados anexados ao e-mail e com senha, baseada nos identificadores de titular presentes na requisição. As instruções para abrir o anexo e visualizar o resultado são encaminhados no e-mail.

                Requisições com status Finalizada não podem mais ser editadas. Clicando sobre o número da requisição com esta finalidade, a tela apenas exibe os campos, acrescentando, na parte inferior, as mudanças de status que ocorreram.

                f. Abandonar

                Durante o ciclo de vida da requisição, pode ser necessário interromper a demanda do titular, por diversos motivos. Para manter o registro da solicitação sem finalizá-la, está disponível a opção de Abandonar uma requisição.

                Uma requisição pode ser abandonada a qualquer tempo, exceto quando ela já está Finalizada.

                Quando o botão é acionado, o Encarregado de Dados é solicitado a informar o motivo do abandono.

                O motivo será encaminhado para o titular no endereço de e-mail informado na requisição.

                Por fim, a requisição passa para o status Abandonada. Se a requisição estiver Em Processamento, os retornos recebidos posteriormente serão desconsiderados.


                03. RECURSOS ADICIONAIS

                a. Chat

                O botão de Chat permite que o Encarregado de Dados envie mensagens sobre determinada requisição para os participantes da conversa, que inicialmente é o titular dos dados pessoais, mas que podem ser outras pessoas, adicionadas à conversa conforme necessidade.

                Os participantes serão notificados de novas mensagens pelos canais informados ao serem adicionados à conversa (o titular será notificado no e-mail informado na requisição). Eles poderão responder às notificações, e estas respostas serão registradas no chat, podendo ser consultadas posteriormente pelo Encarregado de Dados.

                 

                b. Reenvio

                O botão Reenvio permite que o resultado da consulta de dados seja encaminhado novamente para o endereço de e-mail informado na requisição. Está disponível apenas para requisições com status Finalizada ou Abandonada.


                  ↑ início

                9. Relatório Dados do Titular

                Consiste na permissão de acesso facilitado e seguro sobre o tratamento do dado do titular e atendimento ao princípio do livre acesso.

                O relatório ainda não possui definições nem modelo divulgado pela ANPD - Agência Nacional de Proteção de Dados, portanto, fica sob a responsabilidade do cliente elaborar seu relatório, de acordo com as necessidades e entendimento da empresa. Lembrando que no mesmo devem constar os dados pessoais/sensíveis e o motivo de uso dos mesmos.

                  ↑ início

                10. Responsabilidades do Cliente

                Disclaimer sobre Tratamento de Dados Pessoais/Sensíveis no âmbito dos Produtos TOTVS S.A.

                Ao adquirir o Produto TOTVS, o cliente será o agente controlador dos dados pessoais e/ou sensíveis, conforme expressamente previsto na Lei Geral de Proteção de Dados, de seus usuários, funcionários, colaboradores, fornecedores, prestadores de serviços, dentre outros e, como tal, deverá, por sua conta e risco, realizar o enquadramento, processamento, inserção e todo e qualquer tratamento dos dados, informações e fluxos de dados pessoais, sendo, pois, exclusivamente responsável por tomar as decisões referentes ao tratamento de dados pessoais e cumprir todas as disposições, legislações e normas brasileiras, e, no que lhe couber, as legislações e normas estrangeiras, que regulam os direitos à privacidade e proteção de dados pessoais, incluindo, mas não se limitando, a Lei brasileira nº 13.709/2018 (“Lei Brasileira de Proteção de Dados”) e a Lei brasileira nº 12.965/2014 (“Marco Civil da Internet”), e, quando aplicável, o Regulamento Geral de Proteção de Dados da União Europeia (GDPR - General Data Protection Regulation nº 679/2016) (doravante denominados simplesmente “Legislação”).

                Importante!

                • O cliente deverá buscar, por sua conta, risco e ônus, orientação jurídica específica para garantir a observância da Legislação aplicável, sendo único e integralmente responsável por qualquer falha ou descumprimento da Legislação.
                • Caberá exclusivamente ao cliente em adequar os processos internos e/ou externos dentro do que a LGPD exige, sendo pois, o responsável, como controlador, pelo tratamento de dados pessoais (ou sensíveis).

                 ↑ início

                Eventos webinar LGPD

                Espaço Legislação





                 ↑ início

                FAQs

                FAQs


                I - Anonimização

                1 - A anonimização de funcionários já está disponível no produto? Como funcionará? 

                Hoje está disponível a anonimização do candidato, solicitada a partir do Portal do Candidato. Para as demais personas, será liberada uma solução de anonimização nos próximos releases.
                A anonimização dos dados será realizada por meio da integração dos ERPs com o SGDP."

                2 - A rotina de anonimização não anonimiza todo o processo? Se sim, qual o sentido de anonimizar o campo? Ou é por campo marcado?

                São 2 etapas. A anonimização do candidato se dará pela exclusão do registro (desde que esse não possua nenhum vinculo). A anonimização das demais personas (ex: funcionário), está em fase de desenvolvimento.

                3 - A Totvs irá disponibilizar alguma versão com os dados previamente classificados de acordo com a anonimização?

                Nossa configuração básica de campos sensíveis/pessoais foi disponibilizada e já direciona o básico para anonimização, devendo ser revisto pelos clientes.

                4 - Anonimizar indica que não teremos mais nenhum registro desta persona no produto?

                Está em desenvolvimento uma solução para que seja possível uma anonimização de todos os papéis (funcionário, candidato, etc...) mapeados no produto. Desta forma, não será possível mais identificar os dados do titular anonimizado.

                5 - Haverá alguma API de integração para realizar as consultas? Ex. Um ex funcionário acessa nosso site solicitando informações sobre o seu cpf, podemos ter estes dados em outros sistemas. Teremos que buscar as informações manualmente, ou terá esta consulta integrada?

                Está em análise a possibilidade de solicitação de atualização/consulta de dados do titular por meio de uma plataforma unificada para futuras soluções.

                6 - O que tem disponível de anonimização??

                As tratativas de anonimização estão em desenvolvimento por meio de um novo produto (TOTVS Privacidade de Dados) que irá se integrar ao ERP do cliente, independente da Linha, para apoiar na gestão de permanência dos dados pessoais. Além disso, em todos os produtos serão desenvolvidos artefatos para possibilitar ao cliente, definir os prazos que essas informações ficarão no sistema. A previsão inicial é entregar na 12.1.33 (Outubro/2021).

                II - Audit Trail

                1 - Ainda é necessário alguma licença  para gerar as triggers no Audit Trail ?

                Não será necessária licença. O Audit Trail não utiliza uma licença diferente do que as já embarcadas no produto.

                III - Configuração de Campos Pessoais e Sensíveis

                1 - A partir de qual versão foi disponibilizado a configuração de proteção dos campos Pessoais e Sensíveis da LGPD ?

                Está disponível a partir do Release 12.1.27 (Janeiro/2020).

                2 - Além de validar o mapeamento dos campos, devo efetuar outro procedimento?

                Além da validação dos campos configurados e liberados pela TOTVS, é necessário validar também os campos pessoais e sensíveis e suas atribuições (enquadramento/classificação/justificativas/anonimizável) em cada módulo.

                3 - Essa rotina de configuração de campos podem ser aplicados a campos customizados ?

                Pode sim. Você pode incluir campos conforme a sua necessidade e entendimento após a validação dos campos sugeridos pela TOTVS.

                4 - Esta classificação já vem com um padrão? E ai o cliente pode modificar conforme o seu entendimento?

                Essa classificação é apenas sugestiva, o cliente terá total controle e responsabilidade sobre ela conforme o seu entendimento construído após a sua validação de campos.

                5. Esta classificação já vem com um padrão? O cliente pode modificar conforme o seu entendimento? (Configuração de Campos Protegidos).

                Essa classificação é  sugestiva. O cliente pode fazer alterações sobre ela conforme o seu entendimento.

                III - Consentimento

                1 - Como e quando devo elaborar e solicitar o consentimento de uso dos dados do titular?

                Para informações sobre o consentimento consultar documentações disponíveis na Página TOTVS Linha Logix/Páginas Centralizadoras/LGPD - Lei Geral de Proteção de Dados, item Consentimento.

                IV - Criptografia

                1 - Como configurar a criptografia das informações?

                A TOTVS aconselha que seus clientes utilizem o recurso "Criptografia de Dados Transparente (TDE)" do SGBD do produto. Para informações sobre o criptografia, consultar documentações disponíveis na Página TOTVS Linha Logix/Páginas Centralizadoras/LGPD - Lei Geral de Proteção de Dados, item Criptografia.

                V - Integrações e Protocolos Inseguros

                1 - Como posso garantir a segurança das integrações existentes no produto?

                Estão disponíveis no TDN, orientações sugestivas para incremento de segurança em integrações, como por exemplo o uso de SSL para implementação em APIs, HTTPS, etc. A segurança de acesso as rotinas de integrações é definida pelo cliente assim como os campos pessoais e sensíveis são logados por meio do Log de Auditoria para LGPD.

                Para informações sobre protocolos, consultar documentações disponíveis na Página TOTVS Linha Logix/Páginas Centralizadoras/LGPD - Lei Geral de Proteção de Dados, item Protocolos.

                VI - Log de Auditoria

                1 - E quem trabalha via TS? Vai pegar o IP do servidor, como saber quem foi?

                O controle de log/auditoria disponibilizado registra alterações baseadas no usuário logado, registrando com essa informação.
                Quando o acesso for realizado via Citrix, GoGlobal ou RDS, o IP registrado será do servidor, porém ficará registrado qual foi o usuário que realizou a manipulação dos dados.

                Para informações sobre o Log de auditoria, consultar documentações disponíveis na Página TOTVS Linha Logix/Páginas Centralizadoras/LGPD - Lei Geral de Proteção de Dados, item Auditoria dos Dados.

                VII - Segurança de Dados

                1 - Como esta sendo tratado a segurança dos relatórios do sistema, uma vez que eles são gerados em forma de TEXTO nas pastas temporárias para posteriormente serem visualizados, podendo ser copiados e vazados sem criptografia ou recurso de segurança?

                Neste caso, o cliente é responsável pela gestão da segurança dessas informações. É responsabilidade do cliente, como controlador, proteger a camada de banco e sua infraestrutura, de forma a atender aos requisitos de segurança, aos padrões de boas práticas e de governança e aos princípios gerais previstos nesta Lei e às demais normas regulamentares.

                2 - Como poderá ser configurada a segurança dos dados e realizada sua manutenção?

                Para informações sobre como realizar a configuração consultar documentações  disponíveis na Página TOTVS Linha Logix/Páginas Centralizadoras/LGPD - Lei Geral de Proteção de Dados, item Segurança das Informações.

                3- Como proteger os dados dentro do produto?

                O primeiro passo para a proteção dos dados é o mapeamento da informação por meio da ferramenta Configurador de Campos Pessoais de cada produto. A configuração de campos tem como objetivo controlar a permissão e registrar o acesso aos dados da LGPD. O cliente deverá avaliar o mapeamento mínimo disponibilizado pela TOTVS e alterá-lo conforme julgar necessário.

                Para informações sobre o proteção de dados, consultar documentações disponíveis na Página TOTVS Linha Logix/Páginas Centralizadoras/LGPD - Lei Geral de Proteção de Dados, item Segurança das informações.

                4- Consigo bloquear/mascarar o acesso de usuários a campos pessoais/sensíveis apresentados em telas e listagens?

                A segurança dos dados no produto Logix é por rotina (programas), desta forma, se o usuário logado possui acesso a rotina/programa, terá acesso a todos os dados apresentados por ela.

                Para informações sobre o proteção de dados, consultar documentações disponíveis na Página TOTVS Linha Logix/Páginas Centralizadoras/LGPD - Lei Geral de Proteção de Dados, item Segurança das informações.

                5- É possível verificar quem e quando acessou dados de funcionários e fornecedores?

                Sim, quando algum dado sensível for visualizado será registrado em log, desde que, esteja com esse campo marcado nos parâmetros de segurança.

                Para informações sobre o proteção de dados, consultar documentações disponíveis na Página TOTVS Linha Logix/Páginas Centralizadoras/LGPD - Lei Geral de Proteção de Dados, item Segurança das informações.

                VIII - Relatório Dados do Titular

                1 - Há roadmap para implementação de um relatório com a utilização dos dados pessoais no sistema? Por exemplo quais dados do usuário estão no sistema?

                Embora a ANPD não deixe claro como essa disponibilização deve ocorrer (não há definição se é por meio de relatórios, páginas, ou alguma outra forma.), entendemos que a conciliação poderá se dar por meio do relatório de dados do titular.

                Está em análise a construção do relatório de dados do titular para liberação em versões futuras do produto.

                IX - Relatório de Dados Pessoais e Sensíveis

                1 - No caso de relatório customizados e/ou planilhas, teremos que ajustar as customizações?

                Se esses relatórios exibem dados pessoais, deverão ser ajustados.

                X - Dúvidas gerais sobre a LGPD

                1  - A TOTVS tem algum material para enviar ao cliente quanto ao conhecimento do LGPD no caso da necessidade de pegar a base dele para analisar erros reportados no qual não foram simulados internamente?

                O time de privacidade é quem está conduzindo as questões de proteção de dados nos processos internos da TOTVS, é possível que se estabeleça novas ferramentas e regras para assegurar a proteção de informações dos clientes nos processos de atendimento.

                2 - As customizações estão sendo contempladas com todas implementações da LGPD?

                Informações referentes às customizações deverão ser tratadas diretamente com os canais de comunicação da mesma. Consulte a página Framework - Documento de Referência para obter detalhes sobre as implementações de framework que podem ser utilizadas para tratamento de dados pessoais/sensíveis.

                3 - Caso minha empresa utilize apenas o módulo de Gestão de Pessoas, folha de pagamento, quais são as aplicações da LGPD? A empresa não utiliza o portal do candidato.

                As aplicações da LGPD precisam ser avaliadas conforme os tratamentos de dados realizados pela empresa. É importante avaliar com o jurídico de sua empresa qual o direcionamento e utilizar nossas páginas com conteúdo sobre o tema como referência do que pode ser tratado via produto.

                4 - Como o candidato consegue consultar o uso de seus dados pessoais? Será por meio do site da empresa?

                Será por meio do próprio Portal do Candidato, onde hoje existem as opções de controle de consentimento de uso de dados e solicitação de anonimização.

                5 - Essas atualizações para a LGPD já estão disponíveis?

                Sim, estão disponíveis na página Patch de Atualização