Manual Operacional Versão 0.6

Transcrição

1 Manual Operacional SISTEMA NACIONAL DE GESTÃO DE INFORMAÇÕES TERRITORIAIS SINTER MÓDULO DE INFORMAÇÕES REGISTRAIS E NOTARIAIS MODELO DE COMUNICAÇÃO COMITÊ TEMÁTICO REGISTRAL E NOTARIAL DO SINTER 26 DE OUTUBRO DE 2017

2 ÍNDICE CAPÍTULO 1 INFORMAÇÕES GERAIS HISTÓRICO DE VERSÕES INTRODUÇÃO... 4 CAPÍTULO 2 REGRAS DE ACESSO E VEDAÇÕES... 4 CAPÍTULO 3 PADRÕES DE ASSINATURA DIGITAL... 5 CAPÍTULO 4 SERVIÇO ELETRÔNICO DE COMUNICAÇÃO MODELO I - CENTRAIS TRANSFERINDO INFORMAÇÕES PARA UM REPOSITÓRIO DO SINTER MODELO II - CENTRAIS ATUANDO COMO NÓS ATIVOS DO SINTER Pesquisas Simples Consultas Estruturadas Mineração de Dados ACORDO DE NÍVEL DE SERVIÇO

3 CAPÍTULO 1 INFORMAÇÕES GERAIS 1.1 HISTÓRICO DE VERSÕES Data Versão Descrição Autor Revisor 27/06/ Versão preliminar RFB 04/07/ Alterações de campos, classes e domínios. Comitê Notarial e Registral Consolidação - Luis Orlando 01/08/ Alterações de nomenclatura de campos, criada nova classe em RI (DireitosOnusRestricoes), alteração de domínios e de regras de validação. Comitê Notarial e Registral Consolidação - Luis Orlando 08/08/ Revisão de Domínios, Padrões de Assinatura Digital, Padrões de Conexão e Regras Gerais. Comitê Notarial e Registral Consolidação - Luis Orlando 28/08/ Revisão de Domínios e Tipos Básicos Comitê Notarial e Registral Consolidação - Luis Orlando Alteração de Classes e Domínios de Notas. Alteração na ordem e nomenclatura dos capítulos do Manual. Alteração no domínio de TipoImovel e Acessao dos Registros de Imóveis. Alteração nas classes Pessoa e PessoaFisica (Classes Comuns aos notários e registradores). Transferência da Classe Imóvel, Área, InfoCadastroImobiliário e ValorFiscal para as classes comuns aos notários e registradores. 13/09/ Transferência dos domínios UnidadeArea e TipoImovel para domínios comuns aos notários e registradores. Comitê Notarial e Registral Consolidação - Luis Orlando Transferência Domínio TipoRefCadastral de Classes Comuns para domínios RTD Criação da Classe InfoCadastroImobiliário e domínio CadastroImobiliário Estabelecimento de dois modelos diferentes de comunicação entre as Centrais de Serviços Eletrônicos dos Registros e Notas e o SINTER. Padrões de Assinatura Digital. Serviço de Ofício Eletrônico da Administração Pública Federal. 3

4 19/10/ Alteração no endereço, eliminando Complemento1 e Complemento2 e adicionando uma Lista<Complemento> limitada a 3 complementos. Criação da Classe Complemento. Alteração do nome do domínio PaisOrigem para Pais Ateração do nome da entidade TipoCapacidadeCivil para CapacidadeCivil Detalhamento do modelo 2 de comunicação Divisão do Manual em dois documentos Modelo de Dados e Modelo de Comunicação 1.2 INTRODUÇÃO Este módulo apresenta o conjunto de definições necessárias à integração entre o SINTER e as Centrais de Registros de Imóveis, de Títulos e Documentos e Pessoas Jurídicas e a Central Notarial de Serviços Eletrônicos Compartilhados por meio de serviço eletrônico de comunicação. As definições deste módulo envolvem especificações de assinatura digital, padrões de conexão, políticas de segurança da informação, perfis de acesso e modelos de comunicação entre o SINTER e as centrais de registros e de notas. Os dados poderão ter persistência local ou remota, conforme modelo de comunicação escolhido pelo respectivo gestor dos dados. CAPÍTULO 2 REGRAS DE ACESSO E VEDAÇÕES O acesso às camadas notariais e registrais será disponibilizado para usuários devidamente autenticados mediante certificado digital ICP-Brasil A3 e autorizados por meio de concessão de perfil de acesso nos moldes da Portaria RFB/Sucor/Cotec nº 73, de 08 de dezembro de O acesso aos dados notariais e registrais por meio do Sinter estará restrito a servidores da Administração Pública Federal, da Corregedoria Nacional de Justiça e do Ministério Público Federal. Todos os acessos serão controlados em registro de log no Sinter, com previsão de auditoria sazonal para verificação do cumprimento das políticas acordadas entre os órgãos. 4

5 Dado o comando expresso no art. 236 da Constituição Federal, os serviços notariais e de registro são exercidos em caráter privado, por delegação do Poder Público, ficando expressamente vedado a órgãos ou agentes públicos emitir certidões, franquear acesso ao público ou divulgar as informações disponibilizadas pelos serviços de registros públicos e pelos serviços notariais ao SINTER, sob pena de responsabilização administrativa, civil e criminal previstas na legislação vigente. As informações notariais e registrais contidas no Sinter serão objeto de consultas ou de mineração de dados, sempre por usuários devidamente qualificados e autorizados na forma do art. 41 da Lei nº , de 7 de julho de Entende-se processos de mineração de dados como sendo aqueles que, mediante análise de grandes quantidades de registros, visam identificar padrões ou relações existentes nos dados. A mineração de dados somente poderá ser executada em ambiente próprio da RFB ou do Sinter, podendo ser centralizado ou descentralizado. O Sinter e as Centrais de Serviços Eletrônicos Compartilhados executarão as políticas de segurança da informação necessárias para proteção dos dados contra alteração indevida, perda, acesso, extração, exportação, transmissão e divulgação não autorizados. CAPÍTULO 3 PADRÕES DE ASSINATURA DIGITAL As comunicações entre o SINTER e as Centrais de Registros de Imóveis, de Títulos e Documentos e Pessoas Jurídicas e de Notas serão feitas exclusivamente com uso de certificação digital. Os dados transmitidos pelos cartórios para as Centrais de Serviços Eletrônicos Compartilhados serão assinados digitalmente no padrão ICP-Brasil ou na forma do 2º do Art. 10 da Medida Provisória , de 24 de agosto de 2001 (verbis): Art. 10. Consideram-se documentos públicos ou particulares, para todos os fins legais, os documentos eletrônicos de que trata esta Medida Provisória. (...) 2o O disposto nesta Medida Provisória não obsta a utilização de outro meio de comprovação da autoria e integridade de documentos em forma eletrônica, inclusive os que utilizem certificados não emitidos pela ICP-Brasil, desde que admitido pelas partes como válido ou aceito pela pessoa a quem for oposto o documento. Salienta-se, entretanto, que a comunicação entre as Centrais de Serviços Eletrônicos Compartilhados e o SINTER será realizada, exclusivamente, utilizando-se o padrão ICP-Brasil. Quanto à necessidade específica de assinatura e encaminhamento de dados em formato JSON, o padrão aplicável deverá ser o CAdES (CMS Advanced Electronic Signature). O 5

6 SINTER validará as assinaturas digitais, com checagem à LCR (Lista de Certificados Revogados), no momento da recepção das informações. CAPÍTULO 4 SERVIÇO ELETRÔNICO DE COMUNICAÇÃO A comunicação dos cartórios com o SINTER será realizada por meio de Centrais de Serviços Eletrônicos Compartilhados, em conformidade com os Provimentos 18/2012, 47/2015 e 48/2016 do Conselho Nacional de Justiça. Na comunicação entre as Centrais de Serviços Eletrônicos Compartilhados e o SINTER serão utilizados serviços web (WS - WebServices) como forma de integração entre os pontos de comunicação do sistema. Esses serviços serão desenvolvidos utilizando o padrão REST (Representational Transfer Protocol). O formato para a troca de informações entre os sistemas envolvidos será o JSON (JavaScript Object Notation), adotado pelo e-ping (Padrões de Interoperabilidade de Governo Eletrônico) para linguagem para intercâmbio de dados do governo federal. Comunicação será via HTTPS (TLS 1.2 ou superior) com uso de certificado de máquina ICP-Brasil, emitido em nome do órgão integrante do SINTER. A implementação do protocolo utilizado deve garantir a verificação das LCR dos certificados envolvidos. A comunicação de dados: os algoritmos, protocolos, tamanhos de chaves e modos criptográficos utilizados no armazenamento e no tráfego de dados deverão utilizar os padrões adotados ou recomendados pelo item 2.2 do Documento de Referência da e-ping (Padrões de interoperabilidade do Governo Eletrônico); estando descartado o uso daqueles que apresentem vulnerabilidades conhecidas. A comunicação de atos notariais e registrais entre as Centrais de Serviços Eletrônicos Compartilhados e o SINTER poderá ser feita de duas formas, a critério de cada central, conforme descrito abaixo. 4.1 MODELO I - CENTRAIS TRANSFERINDO INFORMAÇÕES PARA UM REPOSITÓRIO DO SINTER Para este fim, serão utilizados serviços web (WS - WebServices) como forma de integração entre os pontos de comunicação do sistema. Esses serviços serão desenvolvidos utilizando uma interface REST (Representational Transfer Protocol) e internamente o protocolo S3, conforme diagrama abaixo: 6

7 Regras de envio de dados: I. Os extratos deverão ser agrupados em lotes. II. III. IV. O lote de extratos será um arquivo compactado no formato.zip que conterá apenas um par de arquivos: os dados em formato.json e a assinatura digital do lote em formato.p7s. Os arquivos mencionados no item anterior não tem nomenclatura pré-definida. Os lotes serão assinados digitalmente pela Centrais de Serviços Eletrônicos Compartilhados (certificado A1), no padrão PKCS #7 e enviados diariamente. V. O arquivo.json do lote possuirá estrutura similar à descrita no exemplo abaixo: {"datageracao": "15/09/2017", "sequencial": "0001", "extratos": [ {extrato1},{extrato2},{extraton} ] } VI. VII. Campos com valores nulos na origem deverão ser omitidos dos extratos. Não serão formados lotes sem movimento ou vazios. VIII. Os lotes de extratos enviados ao SINTER devem respeitar um limite máximo de extratos por lote. IX. O serviço REST de recepção dos lotes enviará retorno síncrono à Central RTDPJ sobre a validação da estrutura do lote recebido. O relatório de recebimento ou de rejeição conterá, conforme o caso, o número do Extrato Eletrônico, a data e a hora do envio e o número do aviso, autenticado mediante Assinatura Digital. 7

8 X. O serviço de recepção do Extrato Eletrônico no SINTER analisará: a) A autenticidade e a integridade do arquivo digital; b) A observância do leiaute estabelecido. c) Falta de habilitação do remetente; d) Falta de preenchimento de campo obrigatório; XI. XII. XIII. XIV. XV. XVI. Os lotes de extratos que se enquadrem nas situações a, b, c e d do item anterior deverão ser rejeitados e não serão persistidos na base local do SINTER. O relatório de rejeição conterá informações que justifiquem de forma clara e precisa o motivo pelo qual a recepção do Extrato Eletrônico não foi bem-sucedida. Os lotes serão encaminhados para processamento após o recebimento. O Sinter disponibilizará serviço REST para consulta assíncrona do processamento de lotes pela combinação dos parâmetros datageracao e número sequencial. Por meio deste serviço, a Central poderá consultar o relatório completo após processamento de cada lote enviado ao SINTER. O relatório completo do processamento de lotes deverá fornecer ao emitente das informações falhas e inconsistências verificadas no processamento das informações. As inconsistências verificadas pelo serviço de recepção no SINTER serão reportadas no relatório completo e não serão impeditivas do recebimento das informações. Atuarão como um controle de qualidade dos dados e obedecerão os seguintes critérios gerais: a) Nos campos com domínios especificados, verificar se o tipo informado pertence ao domínio especificado. b) Nos campos com formato especificado, validar o formato. c) Verificar inconsistência de dados de CPF e CNPJ de acordo com o cadastro de CPF e de CNPJ; d) As datas relativas a registros deverão ser menores ou iguais à data do recebimento. XVII. XVIII. Depois da recepção bem-sucedida, o Extrato Eletrônico não poderá ser substituído. A retificação do Extrato Eletrônico poderá ser feita somente por meio da geração e transmissão de um novo extrato, consignando no campo apropriado que se trata de um documento de retificação. 4.2 MODELO II - CENTRAIS ATUANDO COMO NÓS ATIVOS DO SINTER As Centrais de Serviços Eletrônicos Compartilhados, mediante atendimento de requisitos mínimos estabelecidos neste manual e homologação pelo Comitê Temático Registral de que trata a Portaria nº 2.160, de 29 de maio de 2017, poderão funcionar como nós ativos do 8

9 Sinter, com ambiente para consulta e mineração de dados sem necessidade de transferência prévia de arquivos para o nodo do Sinter na RFB. O ambiente computacional do convenente, enquanto nó ativo do Sinter, atenderá, além dos requisitos de hardware e software próprios, a configuração de software indicada neste manual composta de frameworks amplamente disponíveis na forma de FOSS (Free and Open Source Software) ou fornecidos pela Secretaria da Receita Federal, a serem homologados pelo Comitê Temático Registral e Notarial, com possibilidade de inspeção e auditoria por parte do convenente de todos os artefatos dos softwares disponibilizados. Os frameworks open-source referidos neste manual são os HiveServer2 (Thrift), Spark e Cassandra da Apache Foundation e o ElasticSearch da Elastic. O Convênio de Colaboração do Sinter, em cada caso, poderá especificar mais detalhes inclusive quanto a: 1. Cadastramento de usuários e perfis de usuários, na forma da Portaria RFB/Sucor/Cotec nº 73, de 08 de dezembro de 2014, 2. Critérios de limitação por usuário, conforme o seu perfil: a. da quantidade elementos de filtros de pesquisa. b. da tamanho do resultado da pesquisa, consulta ou processamento. Além da dimensão em Bytes, o tamanho também poderá ser parametrizado por quantidade, por exemplo, de Matrículas, Registros, Pessoas Físicas ou Jurídicas envolvidas, c. da quantidade de pesquisa ou consulta realizada por período e d. da quantidade e qualificação do recurso computacional; 3. Comunicação de dados como uso de VPN ou tunelamento e respectivas configurações e outros requisitos de segurança, 4. Acordos de nível de serviço, além daqueles aqui descritos. Neste modelo, os nós do Sinter fornecerão serviços para pesquisa simples, consulta estruturada e mineração de dados Pesquisas Simples As Centrais de Serviços Eletrônicos Compartilhados deverão fornecer uma interface de programação RESTful com funcionalidades endereçáveis nos moldes da RFC-3986 da seguinte forma: 9

10 PESQUISA POR CHAVE PRIMÁRIA Onde GET /<entidade>/<índice> <entidade> é uma das entidades descritas no Manual Operacional, Modulo Informações Registrais e Notariais Modelo de Dados. <índice> é a sequência de texto que porventura possa identificar uma instância da entidade especificada no parâmetro <entidade>. Esta funcionalidade será usada para pesquisar por instâncias de <entidade> cujo índice na base de dados seja conhecida pelo cliente PESQUISA POR TEXTO Onde GET /_search?[texto] texto é uma string que será usada como critério de pesquisa. Esta funcionalidade retornará os objetos existentes na base de dados que porventura possuírem texto no seu conteúdo nos moldes do Apache ElasticSearch PESQUISA POR FILTRO Onde GET /<entidade>?<c1>=<v1>[&<cn>=<vn>][&f=<lista>] <entidade> é uma das entidades descritas no Manual Operacional, Modulo Informações Registrais e Notariais Modelo de Dados; <C1> a <Cn> são campos da entidade especificada no parâmetro <entidade>, em que campos estruturados serão indicados por. (ponto); <V1> a <Vn> são possíveis valores dos campos especificados por <C1> a <Cn> e; <lista> é uma lista de strings separadas por, (vírgula) que identificam os campos a serem retornados pela pesquisa. Se este parâmetro estiver ausente, o default é retornar todos os campos de <entidade> especificados neste manual. 10

11 Esta funcionalidade será usada para pesquisar por instâncias de <entidade> que porventura possuam pares campos/valores conforme especificados nos parâmetros PESQUISA POR FILTRO ESTRUTURADO Onde GET /<entidade>?q=<filtro>[&f=<campos>] <entidade> é uma das entidades descritas no Manual Operacional, Modulo Informações Registrais e Notariais Modelo de Dados; <filtro> é JSON com os critérios da pesquisa a ser realizada conforme descrito a seguir; <lista> é uma lista de strings separadas por, (vírgula) que identificam os campos a serem retornados pela pesquisa. Se este parâmetro estiver ausente, o default é retornar todos os campos de <entidade> especificados neste manual. Esta funcionalidade será usada para pesquisar por instâncias de entidade que porventura atendam ao filtro especificado. O filtro é um objeto JSON com a seguinte estrutura: Filtro Campo Descrição Tipo Obrig. Domínio/Formato <Nome do Campo> Nome do campo referido pelo filtro Alfanumerico Não Campos das demais entidades definidas neste manual criterio Critério de Pesquisa Numérico Não Ver domínio Criterio min Valor mínimo do campo Numérico Não max Valor máximo do campo Numérico Não anomes.inicial anomes.final data.inicial data.final argumento texto tab.criterio Ano e mês inicial do campo em casos de data Ano e mês final do campo em casos de data Data inicial do campo em casos de data Data inicial do campo em casos de data Numérico Numérico Data e Hora Data e Hora Alfanumerico Alfanumerico Alfanumerico 11

12 tab.nomes tab.col selecao Alfanumerico Alfanumerico Vetor O campo critério assumirá um dos valores abaixo e deverá ser interpretado conforme o tipo do campo a que se referir. Caso o critério exija parâmetros, a coluna Parâmetros enumera os campos de Filtro que poderão ser usados para passá-los ao servidor. O campo seleção poderá conter itens de filtro que façam parte de um domínio enumerado. Criterio Domínio dos critérios de pesquisa Aplicável à Valor Descrição Parâmetros Inteiro 1 Igual a min 2 Diferente de 3 Menor ou igual a 4 Maior ou igual a 5 Qualquer número 6 Na lista 7 Não consta na lista 8 Entre Data 1 Igual a anomes.inicial 2 Diferente de 3 Na lista 4 Não consta na lista 5 Expressão regular 6 No mês 7 Fora do mês 8 No ano 9 Fora do ano 10 Vazio max anomes.final data.inicial data.final argumento 12

13 11 Não vazio Alfanuméri co 1 Começa com texto 2 Termina com tab.criterio 3 Contém tab.nomes tab.col 4 Não contém 5 Igual a 6 Qualquer texto 7 Vazio 8 Não vazio 9 Na lista 10 Expressão regular 11 Não consta na lista 12 Menor que 13 Maior que 14 Não começa com 15 Entre 16 Não contém expressão regular 17 Não termina com 18 Diferente de 19 Menor ou igual 20 Maior ou igual 50 Consta na tabela 51 Não consta na tabela 52 Contém palavras da tabela 53 Não contém palavras da tabela 54 Expressões regulares da tabela 13

14 55 Não contém expressões regulares da tabela Numérico 0 min 1 Começa com dígito 1 max 2 Começa com dígito 2 3 Começa com dígito 3 4 Começa com dígito 4 5 Começa com dígito 5 6 Começa com dígito 6 7 Começa com dígito 7 8 Começa com dígito 8 9 Começa com dígito 9 10 É igual a zero 11 Não é zero 12 É número redondo 13 Não é número redondo 14 É vazio 15 Não é vazio 16 Na lista 17 Não consta na lista Consultas Estruturadas O nó do Sinter fornecerá serviço de consultas do tipo SQL mediante a utilização do framework Apache HiveServer2. Além do detalhamento da conexão e requisitos de segurança, o Convênio de Colaboração poderá definir a possibilidade de outros serviços além deste de simples consulta por meio da definição de interface Apache Thrift. 14

15 4.2.3 Mineração de Dados O nó do Sinter fornecerá serviço de mineração de dados mediante a utilização do framework Apache Spark sobre Apache Cassandra. Além do detalhamento da conexão e requisitos de segurança, o Convênio de Colaboração definirá a forma de inclusão no respectivo nó do Sinter do código executável que procederá a mineração bem como os critérios de estabelecimento dos limites de utilização dos recursos computacionais do nó e da rede. 4.3 ACORDO DE NÍVEL DE SERVIÇO Disponibilidade mínima Tempo Médio de Recuperação MTTR Indicador de Quantidade de Ocorrências - IQOM Horário de Acesso Usuários Simultâneos Relatórios Simultâneos 95% de disponibilidade 2 horas 2 ocorrências/mês Das 07:00 às 24:00 horas usuários 500 relatórios 15