€ 07 TEL Laboratério de Sistemas Integraveis Tecnolégico PROJETO SREI Sistema de Registro Eletrénico Imobiliario PA 1.9.5 — Requisitos para Software SREI Titulo i PROJETO SREI: PA 1.9.5 — Requisitos para Software SRE! Versao Verséo 1.1 release 12 Data da liberagao 15/02/2011 Classificagao ___|LSI-TEC:Restrito Autores Gislaine Bueno, Volnys Bernal, Adriana Unger, Marcelo _ | Silva Propriedade LSI-TEC @ CNJ Restri¢des de acesso_| LSI-TEC, CNJ e ARISPProvesso n®. 41250 Sonos leg Terie mec bx Sumario Sumari 1 NTR 2 visAc 2a 22 3. REQUISITOS PARA SOFTWARE SREI.. 91.9 Bn. 84.4 a2 321 322 3.23 3.24 33 3.3.1 332 333 34 B44 342 343 aaa io ;ODUGAO (0 GERAL DA ORGANIZACAO DOS REQUISITOS PARA SOFTWARE SREI. ESCOPO DE COMPONENTES DO SREI ENVOLVIDOS NA CEATIFICAGAO. 5 (OBRIGATORIEDADE 00 ATENDIMENTO 00S REQUISITOS. 6 SEGURANGA sn Controle de versio do software. Gerenciamento de usuarios Identiticagéo e autenticagdo dos usuarios. Controle da sesso do usuario. Autorizagao e controle de acesso.. js 7 Integridade e disponibilidade dos registros eletrénicos. eee 18 ‘Seguranga dos canais de comunicagéo, 19 Rastreabilidade dos eventos. Tempo. se 0 Notificagao de ocorénCIAS..ue.nn 1 Documentagéo do software REI... 24 ASSINATURA DIGITAL. 25 Certiicado digital 2 Assinatura alta. 27 Carimbo de tempo 31 Centiicado de atributo. 92 MoD€L0 De pADOS.. 33 Imével e matricula.. 33 Pessoa. a7 POA dO none 39 FUNCIONALIDADES: A Goral, ed 4a Atendimento presencial 44 Recepgéo de titulos... Anélise do pedido — captura inicial. Came | Versio |" Giassificagae [Pagina PROJETO SREI: PA 1.9.5— Vi2r12 s 2/71 Requistos para Software SEI 2) ISU TEL eaProceso n? S12 854 Fis. rv. OST TEL sen BAS 3.4.6 347 348 3.4.9 3.4.10 3.4.11 9.4.12 8.4.13 3.4.14 34.15 3.4.18 3.4.17 3.5 DOCUMENTO ELETRONCO.. 4 _ REFERENCIAS BIBLIOGRAFICAS... rwvonbiacor.br Anélise do pedido. Verificagao do contraditério. sn Primeira qualificagéo eletrénica da matricul. Qualifcagao e andise. Verificagao de valores Consultas automaticas... Tratamento ¢ suscitagéo de davidas Controle do prazo de prenotacéo, Consuitas internas a0 sistema vunrinmne Geragao do protétipo do resultado do pedido. Liberagao do pedido... Entrega do pedico. Interagao com SAEC... Titulo Soa Versao_| ificagao | Pagina PROJETO SREI: PA 1.9.5— vierti2 | LS-TECRestrito | 3/71 Requisitos para Software SREIproceso nf 31287 L Fis. n°, CST TE sex ‘bate de Sates lr cle S unnEEEEEEENEeeneeemee sours be 1. Introdugao Este documento descreve os requisitos que devem ser atendidos pelos softwares de Sistema de Registro Eletrénico Imobiliério (SREI) Tais requisitos devem ser utilizados pelos desenvolvedores e fornecedores para direcionar as implementagées de software de SREI. proceso de certificagéo de software SREI verifica a conformidade do software em telag&o ao atendimento destes requisitos. lassificagao.) | Pagina viert2 | LSETEC:Restito | 4/77 Requisitos para Software SRE!Processo r* 77S Fis, ASUTEC ser 2 Vis&o geral da organizagao dos requisitos para software SREI Esta secdo apresenta uma visdo geral da organizacao dos requisitos para software SRE, abordando os seguintes topicos: * Escopo de componentes do SREI envolvidos na certificaco; * Organizagao dos requisitos; '* Obrigatoriedade do atendimento dos requisitos. 2.1 Escopo de componentes do SREI envolvidos na certificagao © processo de certificagdo do software SREI envolve ndo somente do programa SRE, mas também os componentes que o compée. A seguir est apresentada uma relagao de componentes que sao considerados como integrantes do SREI: © SGBD (Banco de Dados) e conectores; ‘* Arquitetura do S-RES (cliente/servidor, ASP, Mainframe, etc.); * Componentes do tipo web dinamicos (Applet, ActiveX, etc.); * Sistema de diretérios (AD, LDAP, etc.); * GED. Ao submeter um software de SREI para um proceso de certificagdo, o solicitante deve identificar e descrever cada um de seus componentes, além do ambiente operacional utilizado para sua execugdo. A descrigdo deve necesséria para o S-RES funcionar corretamente, incluindo todos os componentes de hardware e software que serao utilizados no processo de certificagao, além dos respectivos parametros que devam ser eventualmente ajustados. \cluir a infraestrutura Titulo: | Versio | Classificagdo | Pagina PROJETO SAE! PA 1.9.5— vi2e42 | LSITEGRestito | 5/71 Requisitos para Software SREIProcesso n? 34125913, Fis. CSTE Serv, Lahore de Sitar ling Teroigo wowace 2.2. Obrigatoriedade do atendimento dos requisitos © Quadro 1 apresenta a classificagéo utilizada para indicar o nivel de obrigatoriedade do atendimento de cada requisito. Quadro 1 ~ Classificacao da obrigatoriedade do atendimento dos requisitos. Cédigo | Obrigatoriedade do | Descricao atendimento do requisito ° Obrigatério O requisite deve atendido de forma integral oc Obrigatério condicional © atendimento integral a0 requisito € obi ‘somente quando for satisfeita uma determinada condigao, R Recomendado atendimento integral a0 requisito no é obrigatério, orém sendo recomendada sua adogao. RC. Recomendado condicional | © atendimento integral a0 requisito néo é obrigatério, porém sendo recomendada sua adocdo, somente quando for satisfeira uma determinada condicao. F Facultative O atendimento ao requisito & opcional. NA. Nao se aplica requisito nao se aplica a esta entidade. Titulo: ae Versao | Classificagao | Pagina PROJETO SRE PA 1.9.5— vi2ri2 | LSITECRestito | 6/71 Requisitos para Software SREIProcesso n? 2/2874 3 Requisitos para software SREI Esta seco apresenta a relagdo de requisitos que devem ser implementados pelo software de Sistema de Registro Eletrénico Imobilidrio (SREI). Os requisitos foram organizados em areas e grupos de requisitos a fim de faciltar ‘seu entendimento. O Quadro 2 apresenta esta organizagao. Quadro 2 - Areas e grupos de requisitos. Area de requisitos Grupo de requisitos SEG | Seguranga Cv _| Controle de versio do software GU_| Gerenciamento de usuarios 1AU__| Identiicagao e autenticacao dos usuarios CSU_| Controle da sesso do usuario ‘ACA | Autorizagao e controle de acesso IDR | Integridade e disponibiidade dos _registros, eletrénicos 'SCC_| Seguranga dos canais de comunicagao RE _ | Rastreabilidade dos eventos T | Tempo NO _[ Noticagao de ocorréncias DS _| Documentagao do software AD | Ascinatura digital Centiicado digital Assinatura digital Carimbo de tempo Certficado de atributo DAD | Modelo de dados IM__[ imével e matricula Pessoa Padido FUNC | Funcionalidades Geral ‘Atendimento presencial Recepodo de titulos ‘Analise do pedida captura incial Analise do pedido \Verificagao do contraditério “Titulo PROJETO SRE: PA 1,9.5— vi2e12 | LSITECRestito | 7/71 Requisitos para Software SREIProcesen icy OST EcL ee Sea ieee Wr Sanat gr Te wn om Primeira qualificacao eletronica da matricula Qualificagdo e analise Verificagao de valores: Consultas automaticas ‘Tratamento e suscitagao de divides Controle do prazo de prenotago Consultas intemas ao sistema Geragao do protétipo do resultado do pedido Liberagao do pedido Entrega do pedido Interago com SAEC DE | Documento eletre As segdes a seguir detalham cada uma destas areas de requisitos. “Giassificacio | PROJETO SREI: PA 1.9.5 — vi2rt2 | LSI-TEC:Restrito Requisitos para Software SREIOS VEE 3.1. Seguranca Esta segio apresenta os requisites relacionados a seguranga do SREI Observacao: No contexto deste documento, o termo “registro” possui duplo sentido. Pode se referir ao “registro imobiliario” ou ao “registro de eventos” no sentido de log. Para evitar esta situap&o, sempre que possivel, quando for necessario se ‘ado 0 termo “anotag&o de event: referir ao “registro de logs" sera Os requisitos de seguranga para software SREI foram divididos nas seguintes areas: * Controle de versa do software; © Gerenciamento de usuarios; ‘+ Identificagao autenticagao dos usuérios; * Controle da sesso do usuario; * Autorizagdo e controle de acesso; + _Integridade e disponibilidade dos registros eletrénicos; * Seguranga dos canais de comunicagao; * Rastreabilidade dos eventos; © Tempo; * Notificagao de ocorréncias; * Documentagao do software. [ Titulo Versio | Classificagao | Pagina PROJETO SREI: PA 1.9.5 — vi2e42 | LS-TEC:Restrito | 9/71 Requisitos para Software SREI 7, Sol 088800Ie} oeAor TE 3.1.1 Controle de versao do software A utilizagéo de controle da verséo do software possibilita associar problemas, funcionalidades e estagio de certificago a uma determinada vers&o, E um controle importante para a seguranca do ciclo de vida do software e, também, para 0 processo de cettificagao do software. Referéncia | Requisito Origem Descrigaio SEG.CV.01_ | Versio do software ABNT NBR ISO/IEC | Todos os componentes do software SREI DEVEM possuir controle de verstio de software. 27002:2005 125.4 ‘segio 0 SREI DEVE possuir funcionalidade que permita a visualizag4o, por qualquer usuario, da verso dos componentes de software utlizados. Para cada componente DEVE constar 0 nome do componerte o nome do fomecedor e a versio do componente. seG.cVv.02 | Controle de versées do software © fomecedor DEVE possuir um repositério estruturado contendo todas as verses dos Componentes (exeautaveis e cédigos-fonte). ‘A partir de uma determinada versao do software de um componente DEVE ser possivel Fesgatar 0 cédigo fonte associado, possibiltando recuperar 0 cédigo fonte para gerago do ‘componente. 3.1.2 Gerenciamento de usuarios Referéncia | Requisito Origem Descrigao. SEG.GU.01 | Identificagao nica do usuario ABNT NBR ISO/EC 27002:2005 11.5.2 ‘Todo usuario DEVE possuir um identificador Gnico no sistema, fundamental para a ‘segao | autenticacao do ustarro, rastreabilidade de eventos, auditoria e segregacao de funcBes, Antes da criagéo Je um identficador para um usudrio, 0 sistema DEVE veriicar a lexisténcia de duplicidade de cadastro deste usuario no sistema (seja um usuario ativo ou Titulo Versio | Classificagio | Pagina PROJETO SREI: PA 1.9.5 — Requisitos para Software SREI vi2r12 | LSETECRestito | 10/71 eg Sid Foe wt ossevold‘ndo alivo) consullando a base de usuarios: nome, CPF, ete SEG.GU02 | Gerenciamento de usuarios © sistema DEVE suportar 0 gerenciamento dos usuérios do sistema com suporie as seguintes funcionaidades: ‘a. Criagdo, modifcacao e inativacao de identificadores de usuarios; b._Criagao, modiifcagéo e remooo de perfis de usuérios. SEG.GU.03 | Remogao de usuérios © sistema NAO DEVE permitir a remocio de identifcadores de usuario do sistema. Quando necessério, deve 0 usuario deve ser inativado, ao invés de removido. SEG.GU.04 | Papeis de ABNT NBR ISO/IEC usuarios 27002:2005 secao 11.22 © sistema DEVE suportar ou permitir configurar, no minimo, os seguintes perfis de Usuarios do sistema (ndo necessariamente com os mesmos nome) ‘+ Solicitante (somente se disponibilizar interface para clientes); © Operador de registro imobilirio: © Oficial; © Escrevente; © Atendente; © Gestor: gerenciamento de usuarios e de perfis de usuarios. * Operator de TI: (© AdministradorT!: configuragao de pardmetros de TI do sistema; (© OperacorT: Iniciagdo, encerramento e monitoragao do sistema; © AuitorTl: Para as atividades de auditoria operacional. Possui privilégio de observar todos os registros (logs) e dados, porém nao possui privlégio para realizar alteragées. + Corregedor. Tals perfis DEVEM estar associados de forma adequada a privilégios de acesso a fungSes do sistema. SEG.GU.05 | Associagao de usuario a sistema DEVE permitir que um usuario possa ser associado a mais que um perfil See Titulo as Versio | Classificacio | Pagina PROJETO SREI: PA 1.9.5 — vi2ra2 | LSETECRestito | 11/71 Requisitos para Software SREL ‘Neg Si ee FURST E wu 08820014[ smilipios paris 3.1.3 Identificagao e autenticagao dos usuarios A identificaco dos usuarios permite discriminar cada usuario individualmente em um acesso ao sistema. Nos sistemas de software, a identificacao é realizada através da associacao de um identificador de usuario a pessoa. A autenticacao de usudrio € o ato de confirmar uma identidade alegada por uma pessoa. A autenticacao pode utilizar um ou mais fatores de autenticacao, baseado em conhecimento, posse ou caracteristica da pessoa, Referéncia | Requisito Origem Descrigao. SEG.IAUO1 | Identifcaggoe | ABNT NBR ISO/IEC | 0 sistema DEVE exigir a Identiicago e autenticagao de cada usuario antes do acesso a | 0 ‘autenticagao do | 27002:2005 — seeao | operacdes ou informagtes restrtas. usuario 182 Este controle NAO DEVE estar presente para operagSes ou informagdes de cardter publica irrestit, SEG.IAU.02 | Método de O sistema DEVE suportar, no minimo, dois métodos de autenticacao: ° autenticagao do @. Autenticagzo baseada em senha; b. Autenticagéo baseada em certiicado digital (chaves assimétricas) SEG.IAU.03 | Procedimento | ABNT NBR ISO/IEC | O procedimento de entrada no sistema (login) DEVE ser configurado para minimizar a | 0 deentradano | 27002:2005 —sego | oportunidade de acesso no autorizado. O sistema de entrada DEVE: Sistema (login) 11.5.1 ‘2. Mostrar um aviso que o sistema deve ser acessado somente por usuarios autorizados; b. Bloquear o usuério apés exceder 0 niimero méximo de tentativas de entradas no sistema (login) sem sucesso. O numero maximo de tentativas de entradas no sistema (login) sem sucesso deve ser um parametro configuravel no sistema; Tien aey nas Versio | Classificagao | Pagina PROJETO SREI: PA 1.9.5 ~ vi2e12 | LS-TECRestito | 12/71 Requisitos para Software SREI DEPP O88800d‘e.Limitar o tempo maxima permitido para o procedimento de entrada; 4. Mostrar as seguintes informagSes apés a finalizago com sucesso do procedimento de entrada no sistema: (© Instante da ultima entrada no sistema (login) com sucesso; © Detaihes de tentativas de enlvaua no sistem (login) sem sucesso, desde a ttima entrada com sucesso. SEG.1AU.04 | Procedo dos | ABNT NBR ISOVIEC | Todos os dados ou parémaros critcosulizados no processo de autenizagao de usuario. parametros de | 27002:2005 seco | DEVEM ser armazenados de forma protegida autenticagao 133 Os dads ou parametros criticos utilizados no processo de autenticagéo DEVEM ser armazenados separadamene dos dados do sistema da aplicacao. SEGIAUO5 | Autenicagéo | ABNT NBR ISONEC | 0 procedimento de enrava no sisiema (ogi), quando da wtizapao do metodo de porsenha. | 27002-2005 secdo | autenicagze baseads em senha DEVE ecaaeneen | 1151 a. Ocular senha que ett sendoinformada plo usu Sistema (oa) 8 Néo rant senha em texto cla: & Validar as informacées de entrada no sistema somente quando todos 0s dados de enirade esverem” completos (denticador “do, usuéio, senna e outs aue everiualmente sejam necessaries). Caso ocore slguma condo de ero, 0 sistena NAO DEVE indicar qual parte do dado de entrada esta correta ou incorreta; SEG.AU.O6 | Autenicagéo | ABNT NBR ISOVIEC | 0 sistema DEVE possuir os segues conroles para autentcacao baseada em usuario © por sens: | 27002:2005 " secao | senna: ramet dee | 11583 aA senha DEVE cer rmazenada de forma coifead uizendo elgorimo hes criticos b. A base de armazenamento da codificagao das senhas dos usuarios DEVE ser proteidaconiraaceeso nao autorzado, SEGIAULOT | Autenicagéo | ABNT NBR ISO/IEC | 0 sstoma DEVE poset interface para que o proprio usudrio modiiue sua propia senha, por senha: 27002:2005 seco | incluindo um procedimento de confirmagao da senha para evitarerros. escolha da 183 senha Titulo” Versio | Classificacao | Pagina PROJETO SREI: PA 1.9.5 — Requisitos para Software SRE! vi2e42 | LS-TECRestrito | 13/71 “83 Sr sig Foye ot osseoddSEGIAUO8 | Autenicagio | ABNT NBR ISONEC | O sistema DEVE vericar a qualdade da senha nomomenio de sua defo ou alerarao porsenha | 270022008 "sept | pel usuaro. patade da | 183 O tistoma DEVE suportar a coniguragto dos partmetros de quadede da sen dos usuarios, permitindo configurar, no minimo: 8 Quaridade mime de caaceres que conpoe sent, 8 Quanidade minima de caracores ni afabticos, SeGiAUG@ [Autenicapéo | ABNT NOR ISONEG | O ssiema DEVE vecara quad da senkaro momento de sa detniio ou alerapao porsenie | 27002:2008 "seq | peo uuario,vetncando no momenta da ua escola pelo usar co 6 wineravelaateqe faisove | 31a por conan, SEGIAUI0 | Atenicarso | ABNT NBR ISONEC | sistema CEVE suporar a ucionalidade de gare os pei da senha poe porsenka:” | 270022008 "seg | ustano Eta nconaldade DEVE poder er haba cu decobiecs pare cada utro perodldede da | 11834 ou classe de ususri (por explo, pode nfo eer convents apcar ext cntle coo Foca dosenkas lentes do crt, somerie aos coaboradores do cat) periodo maximo para troca da senha DEVE ser um parmetro configuravel no sistema. SEGIAUH [Autenicarao | ABNT NER ISONES | O sistema DEVE euporar a funconalade de mped a reutiizardo dos tas N erhes porcanra:” | 2roazino0s seo | tizada pelo usar. reuieeosto. de Ast ‘A quantidade “N’ das diltimas senhas que néo podem ser reulizadas pelo usuario DEVE a ser um parmetro configuravel no sistema, SEGIAU2 | Autencagao 'A cave prvadeassocads&aulnicagio DEVE eer do conhecmontoeacoeso rive do por carticado toute digital: segredo dueheve pivada SEGIAUA® | Autenicapao | RFC S260 © caricad digtl DEVE ser veritado segundo oesabeecido na RFC £280 e nas porearitesdo | top peat normazagbes Ga \CP-as,inclung: dita vaidacao 2 Veriicago da evogap0 do coticado dia ds caifends i Titulo PROJETO SREI: PA 1.9. Requisitos para Software SRE! Versio. | Classificarao | Pagina vizes2 | LS-TECRestito | 14/71digital 'b._Verificagao da aderéncia do propésito de uso do cerlificado digital, SEG.IAU.14 | Autenticagéo ‘A autenticacao reaizada através de certificado digital DEVE gerar prova de forma a ° por certificado garanti a irfetratabildade da autenticagao realizada. digital: (elemento de prova DEVE ser armazenado em local apropriado de forma que possa ser validado no futuro, (elemento de prova DEVE agregar todos os elementos necessarios para sua validagao (Cadoiae de certiticagSo, cortificados dos signatérioa ¢ informagses de revogasso). Irretratabilidade da autenticagao: SEG.IAU.1S | Autenticagio | ICP-Brasil ‘biblioteca criptogréfica ulilizada pelo sistema DEVE atender aos requisitos para software | O por certificado de autenticacao definidos pela ICP-Brasil no MCTS-Volt-Requisitos [REF] digital: requisitos ICP- Brasil SEG.AU.16 | Autenticagao | ICP-Brasil A biblioteca criptog'sfica utlizada na autenticagao DEVE ter homologagao “software de | O por cerificado autenticagéo" da ICP-Brasil digital: homologagao ICP-Brasi SEG.IAU.17 | Autenticagdo | ICP-Brasil A biblioteca criptogafica utiizada pelo sistema DEVE ser capazidentiicar se ocertifcado | O Por certficado digital utlizado na eutenticagao é de uma cadeia da ICP-Brasil ou de uma outra cadela digital: Observacao: A cadzia de certificado, em algumas situacd servacao: A cadzia de certificado, 1agbes, podera ser de outra cadcia, corms por exemplo, na situagdo de convénios com eniidades do exterior SEG.IAU.18 | Autenticagao 0s usuarios que possuem perfs associados a funcionérios DEVEM ser autenticados por dos funcionarios meio de assinatura digital ae th Titulo ee __Classificagao | Pagina PROJETO SRE: PA 1.9.5— vi2ni2 | LSETECRestito [15/71 Requisitos para Software SREIcov TEL 3.1.4 Controle da sessao do usuario A sesso do usuario corresponde a sequéncia de interagdes que ocorrem entre 0 usuario e sistema, da sua autenticagéio até o encerramento da sua interacao com o sistema, Referéneia | Requisite Origem esorigaa SEG.CSU.O1 | Controle da ( sisteria DEVE realizar 0 controle da sesso do usuario, desde a autenticago do usuario | O sesso do até o encerramento da sua sesso de uso. usuario SEG.CSU.02 | Seguranga O sistema DEVE possuir controles de seguranca de forma a impedir a possibilidade de | O contra roubo da roubo da sesso do usuario, sesstio do usuario SEG.CSU.03 | Encerramento | ABNT NBR ISO/IEC | 0 sistema DEVE encerrar a sesso do usuério apés um determinado periodo de | O porinatividade | 27002:2005 11.5.5 | inafividade. O periodo maximo de inatividade DEVE ser um parametro configurével no sistema, SEG.CSU.4 | Invalidagéo O sistema DEVE invalidar o objeto de controle de sesso do usuario apés encerramento da | © anos sesso (seja por logout" ou timeout), de forma a evitar a reutiizagao do objeto de controle encerramento da sesstio de forma néo autorzada, do objeto de controle de sesso * Finalizagéo da sesso executada pelo usuério ao selecionar a opgao sair cu fechar o sistema. ? Expiragdo de sesso ap6s tempo de inatvidade configurvel z Titulo Versio | Classificagao | Pagina PROJETO SREI: PA 1.9.5— vi2ed? | LSETECRestrito | 16/71 Roguisitos para Software SREI neg uid Fopai gol O88800idPrevisibilidade 0s valores utiizados nos abjetos de controle de sessdo DEVEM ser gerados de modo a do objeto de impossibilitar a previsibilidade do seu valor. controle de Limitagode | ABNT NBR ISO/IEC | O sistema DEVE suportar a configuragao de restricao de hordrio de acesso a operagbes | R hordrio para | 27002:2005 segao | sensiveis. determinadas | 11.56 operactes 3.1.5 Autorizacao e controle de acesso A autorizacao representa a habilidade de definir quais entidades (pessoa ou proceso) podem fazer uso de um recurso (operagao, dado, etc), © controle de acesso representa a habilidade de permitir ou negar a utilizago de um recurso (operagéo, dado, etc) por uma entidade (pessoa ou proceso) autenticada Referéncia_| Requisito Origem| Descrigéio SEG.ACAO1 | Impedir 0 ABNT NBR ISO/IEC | O sistema DEVE impedir 0 acesso por entidades nao autorizadas a operacées ou | O ‘acasso por 27002:2005 seco | informagbes restritas, entidades nao | 11.6.1 aulorizadas SEG.ACA.C2 | Configuragao do | ABNT NBR ISO/IEC | O sistema DEVE disponibilizar mecanismos para que seja possivel implementar a politica | O controle de 27002:2005 segio | de controle de acesso atrevés da configurago dos perfis de acesso, considerando os acesso 11.6.4 Papeis do usuario e as oneragées que podem ser realizadas, inclusive permitindo a diferenciagao_ de operacdes de consulta, de incluséo, de allerago e de remogdo, Titulo” verso | Ciassiticagio | Péaina’ | PROJETO SREI: PA 1.9.5 — vi2ri2 | LSETECRestito | 17/74 Requisitos para Software SREI ber sa Fuss F oll 0888001"] considerando também que um mesmo usuario pode assumir mais que um papel. SEG.ACAOS | Controle de | ABNT NBR ISO/IEC | 0 acesso aos dados do SREI DEVE ser realizado somente pelos canals autorizados, com ‘acesso 20s 27002:2005 dados do SREI | 11.6.1 ‘se¢d0 | attuago obrigatéria do mecanismo de controle de acesso. O sistema NAO DEVE permitir acesso aos dados do SRE! por canais ndo autorizados SEG.ACA06 | Delegagso de privlégio Caso 0 sistema implemente delegagao de privilégios, DEVEM ser atendidos os requisitos deserites a seguir Na delegacdo de privlégio, o aribuidor é aquele responsdvel por autorizar a delegago do | prvilégioe'0 delegado aquele quem recebe a delegago do privilégio. Para definicao de uma delegagao de pivilégio,o sistema DEVE: a. Veriicar se 0 atribuidor esta previamente autorizado pare delegar o privlégio; b. Formalizar a delegagéo de privilégio, através de um documento assinado digitalmente pelo atibuidor e amazenar 0 documento em repositério apropriado; . Anotar (log) a efetivagao da delegaao de privilégio, 0 sistema DEVE gerar anotarao (log) da delegagao de privilégio,informando: © atribuidor: O delegado; © motivo; O instante da delegacto; | O periodo de vigéncia | © sistema, antes do uso de uma delegaco de privilégio, DEVE veriicar seu periodo de | vigenoia, °° 3.1.6 Integridade e dispo idade dos registros eletronicos Referéncia | Requisito Origen Descrigao. Eee ier aes “Wersio | Classificagao | Pagina PROJETO SREI: PA 1.9.5 — Requisitos para Software SREI vi2ei2 | LSETECRestito | 18/71@ 1s0 Tec SEG.ORO1 | Verifcagao da O sistema DEVE permit a veriicagéo de integridade dos livros eletrnicos. pieerriede doe A verificagao de integridade DEVE ocorrer: eletrdnicos + No momento da iniciagdo do sistema; + No minimo, uma vez a cada dla. SEG.DR02 | Vericacao da O sistema DEVE possuir funcionalidade para verificagdo da integridade da base de dados integridade dos 2 partir dos livros eletrnicos. eae O sistema do cartério DEVE permitir configurar a periodiciddade com que tal verificaco de usiubasad integrdade & realizada. SEG.IDR.03 | Exportacao dos O sistema DEVE possuir funcionalidade para exporiagao dos regisiros eletrénices, ragitroe 0s regsros DEVEM ser exports na forma de arquvos, em uma estuturahirdrauica Palen equivalente & organizagao arquivistca, Os metadados associados ao registro ou a0 nd de agrupamento DEVEM ‘ser exportados também na forma de arquivos estruturados em ‘campos XML de tipo aributo-valor. SEG.IDR.04 | Importagao dos O sistema DEVE possuir funcionalidade para importagao de registro eletnicos. registros eletronicos SEGADROS | Impedir O sistema NAO DEVE permit a exclusdo ou a modticarao de registros eletrénicos. excusio e 5 a Smeaaie | Asbes de corerdo DEVEM sempre preserva os datos anteriores, registros eletrénicos 3.1.7 Seguranga dos canais de comunicagao Referéncia | Requisito Origem: Deserigao : __ Titulo _ Versdo Classificagao Pagina PROJETO SREI: PA 1.9.5 — Requisitos para Software SREI vi2r12 | LSETECRestito | 19/71 wu Sid su 0882004} FEB 2h!LSU TEL SEGSCC0' | Segurenea aa [ABNT NBR ISO/EG [Caso o astema dopo um componente endl par vabzar a hawaeio con 0 0 comunicagao de | 27002:2005 —segdo | usuario (por exemplo, um browser WEB), @ comunicagao deste componente com o peerertaal ie tacts Sen UEVE ual or des span os copa nates gs a ‘calor, negate de dee © touhaenaalaods oe dates a eine oe caee cae eee anes ea ‘Caso 0 sistema seja composto por componentes distribuidos, a comunicagao entre tais Se0.sc0 | Sequansa, da | ABNT NBR ISONEC | To ents pur nero. sanentaocon buesuesedon Oeveatarares |S cons zrone Spite ani oats meade eine eee oes te es Stet Pssac aohaate saoneeoea es Se an eae cae Samper Pete pe ese beatompen creer 580%. | Sopanea ca amit nil ioonet [A comrieagas co amtora com areas itr PVG wr welch ines ta can | comunicacéo | 27002:2005 seco | com suporte aos sequintes servicos de seguranca: autenticacdo de parceiro, integridade de | Sar can | an ae cae cafatte ot tee a 3.1.8 Rastreabilidade dos eventos A rastreabilidade dos eventos que ocorreram no sistema é possivel quando s&o geradas e mantidas anotagdes* adequadas sobre 0s eventos (logs) que ocorreram no sistema. * Neste documento o termo “anotacao de evento” serd uliizado preferencialmente em substituigao ao termo “registro” letrénico imobildrio". Titulo Versio | Classificagao | Pagina PROJETO SREI: PA 1.9.5 ~ Requisitos para Software SREI vi2e12 | LSTECRestito | 20/71 og’), a fim de diferenciar do “registro ‘nag ou Sig FeTTo osse00ic3“Convém que os registros* (log) de auditoria contendo atividades dos usudrios, excecées e outros eventos de seguranga da informagéo sejam produzidos e mantidos por um periodo de tempo acordado para auxiliar em futuras investigagées e monitoramento de controle de acesso" (ISO/MEC 27002, p.61). Referéncia | Requisito Origen Descricao. Pp seGKEUT | Geracio ‘ABN NBR ISONEC | O sistema DEVE realizar a goracéo de anotagSes dos eventos (logs) relevantes do sistema continua de | 27002:2008 seg | de forma continua, nBo permiindo sua desativacdo. anotagées de | 10.10.1 eventos (logs) SEG.REO2 Aleta de © sistema DEVE gerar alerta quando 0 esparo para armazenamento das anotagées de | O espace ciitico eventos (logs) atingir um limiar critico de ocupacao, a fim de permitr tomada de aces para corretivas a tempo, armazenamento das anotagbes dos eventos, (logs) Inegrdade das | ABNT NER ISO/EC | O sistema DEVE poteger as anctags de eveios (og) presenies nestles de auto | tines “de | 270022008 "sepia | contra aeseo nde sued, wnatora “| 40103 SEGREOS [Evens | ABNT NBR ISO/EC | As thas do autora DEVEM corer nfomages relacionadas, no mire, aos segues | 0 anotados 27002:2005 _segaio | eventos: 10102, 10.104 € | eagso e modicagto de eistos eetrnicos + Operagées privilegiadas; * _Atividades de gerenciamento do ciclo de vida dos usuarios e perfis; ro" desta citago é equivalente ao termo “anotacao de eventos” (log) utllzado preferencialmente neste documento. Tilo Ss Classificacio | Pagina | PROJETO SREI: PA 1.9.5 ~ vi2ci2 | LSETEGRestiito | 21/71 Requisitos para Software SRE! Sid tb keg FUSE wd O8s800ldDelegagio de privilégio; Exportagao e imporiagao de registros eletronicos; Exportagao de registros de auditoria; ‘Acesso aos registros de auditoria; Iniciago @ encerramento do sistema Tentativa de autenticago de usuario e seu resultado (sucesso ou falha); Expiracao e bloqueio do identificador do usuario; Execucdo de atvidades de veriicacdo de intearidade dos registro eletronicos e seus resuitados; + Realizapio de assinatura digital SEG.RE.04 | Conteddo da | ABNT NBR ISO/IEC | As anotapses de eventos (logs) DEVEM conter, no minimo, as seguintes inforragbes: anotagéo de | 27002:2005 sea0 ‘5 evento(log) | 10.10.1 Instanta de oorécia Gata o hor} Nivel de ciicidade; ‘Quando relevante, a identificapao do componente, terminal e usuério associado, SEG.REOS | Interface para sistema DEVE possuir uma interface para visualizacao das anotagbes de eventos (logs) viswalizagéo‘cas No minimo, 0 sistema DEVE suportar a vsualzagao cas anotagbes em ordem cronolegica anotagoes de Talinteface DEVE possuirecesso resto somente aos usudrios eutorizadcs. eventos SEGREDS | Exportago dos O sistema DEVE permitr a exportagao dos dados de aueitoria d tl forma que possam ser registios de visualizados em aplcativo extemo de planitas. auditora 3.4.9 Tempo Referéncia | Requisito | Origam Deserigae Versio | Classificagao | Pagina PROJETO SREI: PA 1.9.5 — vi2ei2 | LSETECRestito | 22/71 Requisitos para Software SRE! “Mag wu Sid “FLS2 ye wt 0888001) » sec.rot [Formato da Toda marcacéo de tempo (data © hora) presente em anotacdes de eventos (logs) representacso exportados DEVE ser representada no formato estabelecido pela {SO 8601:2004 @ RFC de tempo (date 3388, inclundo © horaro locale sua diferenca para 0 UTC. Excegéo somente do carimbo hora) do tempo, que segue RFC 3161. Exemplo: evento no dia 12 de abril de 1985, ocorrdo as 10 horas, 15 minutos e 30 equines no herria de Brasilia fora do horarie de verso, quo corrocponde 0'2horee ates do UTC (Coordinated Universal Time). Sintoxe: 1985-04-12 10:18:30-03:00. Fonte de | ABNT NAR 1Sonec | T2da marcacio de Tempo presente em anolagbes de eventos (ags) DEVE ser baseada om Einctenismo de | 270022008 Sntae | uma font rica e confave de tempo. ; ious Tal fonte de tempo NAO DEVE poder ser altrada pelo usuéio, somente pelo usuario iempo privilegiado (ex. administrador), 3.1.10 Notificagdo de ocorréncias Referéncia | Requisito rigem Descricao SEG.NO.01 | Notifcagao de | ABNT NBR ISO/EC | O sistema DEVE possuir uma interface para que os usuarios do sistema possam notificar ecorréncias | 27002:2005 A.11.6.1 | ocorréncia de eventos criticos, problemas de seguranca, problema de funcionamento do sistema e sugestdes de melhoramentos, SEG.NO.02 | Visualizagto O sistema DEVE fornecer uma interface para visualizagao das notiicagbes de ocorréncias das notificacses, realizadas pelos usuérios. de ocorréncias SEG.NO.03. | Encaminhament | ABNT NBR ISO/IEC | O sistema DEVE permit a configuragao de uma lista de e-mail para o qual devem ser ° ddas | 27002:2006 A.11.6.1 | encaminhados os eventos critices, problemas de seguranca e problemas de funcionamento notificagses do sistema, TTittio” (Glassificagao | Pagina) PROJETO SREI: PA 1.9.5 — Requisitos para Software SRE! vi2r12 | LSLTECRestito | 23/71 meg ou Sid FHS apeel SSO3.1.11 Documentagao do software SREI Referéncia | Requisito Origem Descrigao, SEG.DOC.01 | Manuais do DEVEM exist manuais voltados para: are. + Instalago do sistema; + Configuragao do sistema; + Uso do sistema: SEG.00G.02 | Reteréncia a (Os manuais DEVEM indicar cleramente,no inicio do documento, qual verso do software a versio do que se refere software S€6.00603 | Manual de (Os manuais voltados @ instalagao e configurapéo do sistema DEVEM conter as seguintes instalaggo informagdes: sonfigurecéo do + Visdo geral do sistema, inclundo formas de operagao e requisitos do ambiento; + Instalagdo o configuragso do sistema; + Inslalago e configuragdo dos componentes complementares (ex:: SGBO, sistema operacional, et); + Recomendagao sobre a forma de configuracéo segura do sistema (incluindo seus | componente’): } + _Descrigdo dos perfis ou forma de configuragao dos perfis de usuarios do sistema. SEG.DOC.04 | Configuragao do Caso o sistema utilize um SGBD, 0 manual de configurac&o do sistema DEVE informar SGBD como configurar 0 SGAD de forma a impedir 0 acesso de entidades (pessoas ou outos sistemas) nao autorizadas. SEG.DOC.05 | Operador de O manual de configurac4o do sistema DEVE informar como realizar a configuracao de um backup usuério com perfil de operador de backup no SGBO. i Tito Versio. | Glassifieasao | Pasina PROJETO SRE: PA 1.9.5 — Requisitos para Software SREI vi2e12 | LS-TEC:Restito | 24171 Neg Sd FIST ot 088e001d 203.2 Assinatura digital Esta segdo apresenta os requisites relacionados a assinatura digital de documentos, sendo divididos nas seguintes areas: + Cottificado digital; + Assinatura digital; ‘* Carimbo de tempo; © Certificado de atributo. 3.2.1 Certificado digital Referéncia_| Requisito Origem Descricao. AD.CER.01 | Repositorio de | ICP-Brasil O sistema DEVE permitr a configuragao dos certficados raiz de confianga. Sacateoios tale O sistema DEVE possuir controles de seguranga que garantam a integridade e evite alleracdo ndo autorizeda da relacao de cerlfcados raiz de confianca, AD.CER.O2 | Interpretagdo | ICP-Brasit sistema DEVE ser capaz de interpretar e apresentar os dados presentes no certificado dos campos do digital, incluindo os campos especificos definidos na ICP-Brasil. certiicado da ICP-Brasil AD.CER.O3 | Normas de uso | ICP-Brasil O sistema DEVE atender as normas de uso de certficado definidas pela ICP-Bracil da ICP-Brasil AD.CER.04 | Verificagao do | ICP-Brasil O cettificado digital DEVE ser verificado segundo o estabelecido na RFC 5280 e nas ree cer normalizagdes da ICP-Brasil,incluindo: 2. Verificagao da cadeira de certiticacéo; b. Verificagdo da revogacéo do certificado digital (incluindo a validagSo da LCR ou do Titulo Versio. | Classificagdo | Pagina PROJETO SREI: PA 1.9.5 — Requisitos para Software SREI vi2et2 | LS-TEC:Restrito | 25/71 ————nes au Sd Tosatsrel osse00d‘OCSP); ©. Verificago da aderéncia do propésito de uso do certficado digital A verificagao da revogagao do certificado DEVE ser realizada antes de sua utllzagéo. AD.CER.O5 | Resultado da verificacéo do certificade O sistema DEVE considerar os seguinies estados de resultado do procedimento de validagao de um certificado digital + Vélido: cerificade valid: ‘© Invalido: certiicado invatido; ‘ Indeterminado: quando nao é possivel determinar se o cerlficado esta valido ou invalido, geralmente devido a falta de objetos (ex: LCR ou OCSP, certificado da cadeia, etc). AD.CER.08 | Propésito de | RFC.5280 sistema DEVE veriticar se o certificado digital possui o atributo referente ao propésito de uso do uso para assinatura digital: campo key usage definido como Digital Signature e cortificado NonRepudiation. digital AD.CER.O7 | Nivel de | ICP-Brasil © sistema DEVE verificar se 0 certficado digital de assinatura é do tipo ICP-Brasil A3 ou protegéo da A. chave —privada associada ao certificado digital AD.CER.08 | Certiicado de pessoa fisica ou de pessoa juridica de AC cadastrada sistema DEVE verificar se o certiicado digital a ser utilizado & um certficado ICP-Brasil {de pessoa fisica ou um certificado de Pessoa Juridica de uma AC cadastrada, ‘Alguns certificados de pessoa juridica possuem restrigbes de escopo de uso. AD.CER.03 | Cadastramento de ACs emissoras de cettficado PU O sistema DEVE permitr o cadastro de ACs que emitem certificados de Pessoa Juridica, Sea ales setae Verso | Classificagao | Pagina PROJETO SREI: PA 1.9.5— Requisitos para Software SREI vi2r12 | LSHTECRestito | 26/71 ws Nd rs Ha TeeAD.CER.10 | Alerta de validade do certiicado O sistema DEVE alertar o usuario quando da proximidade do término de validade do Certificado digital (ex, com menos de 30 dias de validade). 3.2.2 Assinatura digital ee ee a ADAG || dive ace | econ C letra DEVE atnder aoe requaton prs earn digi otaion ple CP-Bee romittos ae ee AD ADE | Homamgesto [crim Gasca acti gia a DEVE Go Rai Ya eos oe ‘asshole DEVE er alias 30 so WOOT AAD03 | Gercio ae Saree aaron teanice dotocseen araanforapiona ura prado scope documento, esta informagso deve ser apresentada ao futuro signattrio. aad stoma DEVE senea pernra VaLnEaGis 0 Capa de satire SCIEN apapo | ecto as | ICP Gres pore do docavene) poe anata teste iemcnio rc ckavanae on saanou : Bene DEE pote concede Sa oe ee esc gun 6 tn oo Msualzacao do Seedeinee natedomomsagucaae noan0s | Gemgso aa CF ris EVE eaeao rss eh Ga ator aos Ga vata one cana suas a validagao do ae, ota Titulo: Classificacao_ Pagina PROJETO SREI: PA 1.9.5 — Requisitos para Software SRE! vi2r12 | LSETECRestito | 27/71 ou Sd TLS2ig, we 888001) Bb‘ADAD.0S Gerago da | ICP-Brasil O sistema DEVE gerar assinatura ulizando estrutura de atboutos de assinatura digital assinatura aufeenio 4 especiicagao ICP-Brasi assinatura digital com referéncias complotas” (AD- Estrutura de RC). bees eae © sistema PODE ullizar estrutura de atributos de assinatura digital aderente a especticagdo ICP-Brasil“assinalura digital com referencias para valdagio" (AD-RV) somente quando: + For para armazenamento local ao sistema do cartrio, + For garantda a disponiblidade do armazenamentoe da recuperagi futur dos bjetos riecessério para recompor os atibutos aderentes & estutura AD-RC + For capaz de recompor 0 documento assinado cigitaimento com estrutura de atributos de assinatura digital aderente @ especiicagao AD-RC. quando 0 documento for exnortado do sistema, AD.AD.07 Geragao da Além dos atributos necessarios as estruturas AD-RV ou AC-RC, 0 sistema DEVE ser capaz assinatura de inci os seguints atibulos aseinads associados a ascinalue: nein 48 + Instant alegada da assinatura(signingtie); assinados + Alrbutos do signatario; + Compromisso da assnatur: + Local de produgdo da assinatura ADADO8 | Geraggo da O sistema DEVE permite a incluso de certficado de atributo (no atrbuto essinado acsinatura: “atibutos do signatéio) antes da geracto de uma assinalura digital pelo usuario. ae 0 sistema DEVE verifcaro cerificado de alributo antes da geragso da assinalura digital AD.AD.09 Geragéo da | CAdES / XAdES /'| O sistema DEVE sempre incluir 0 atributo de compromisso de assinatura. O compromisso assinalura: | PAES da assinalura DEVE ser requlstado a0 ususrio ‘antes da apicagao da assinatura ou ser compromisso da defnido pel sistema, Nesta stima stuaglo, osietema DEVE informar 20 usuio o tipo de assinatura compromisso defini na futur assinatura. ‘Aassinalura de representantes digitals (documentos digtaizados) DEVE ser realzada com © compromise ‘prova de cago" (proof of creation), quo indica que signatrio gorou © rita “Versio | Classificagao | PROJETO SREI: PA 1.9.5 — Requisitos para Software SREI vi212 | LSETECRestito | 28/71ISTE documento, porém nBo necessariamente aprovou seu contedd. ee Quando a assinatura representa 0 compromisso do signatario com 0 contetido assinado, DEVE ser utlizado 0 compromisso “prova de aprovaco" (oroof of approval, ‘AD.AD.10 | Gerago da O sistema DEVE requsitar, vaidar e incluir 0 atibuto carimbo de tempo de assinatura aceinature: imediatamente apés a geragao de uma asshvatua dia inclsdo do carimbo de tempo de assinatura apAv.t1 | Geraggo da | ICP-Brasi O sistema DEVE incluir, na forma de atibutos da assinatura, 0 objeto de verifcagao do assinature: estado de revogacio (Lista de Cerificados Revogados - LCR ou Online Cerificate Status incluso do Protocol - OCSP) de todos os certficados da cadeia de cerificagao do certiicado do objeto de signataro, worncestel 40 © objeto de verificagto do estado de revogacio a ser incluido DEVE ser obtido apés 0 sain alt proximo period de emisséo de LCR (incusive para o caso de OCSP). Este & conlderado revogardo ideal © objeto de veriicagao de estado de revogarao ideal. Somente apbs 0 recebimenio © veriicario do objeto de veriicagio de estado de revogaca ideal a essinatura deve ser considerada valida, Caso o objeto de verficagao de estado de revogagao indique que o certiicado fol realizado ‘com um certficado revogads,o sistema DEVE: 2) uma mensagem de alerta deve ser encaminhada; )_invatdar 0 documento e retomar o processo de assinatura digital. ‘ADAD.12 | Verifcagdo da O sistema DEVE realizar a veriicagdo da assinatura digital incluindo: Scent ‘+ Verificagdo do carimbo de tempo de assinatura e obten¢ao do instante de referéncia 2 para validagao do certificado; ‘+ Veriicagao do certiicado digital do signatério utiizando como referénecia 0 instante de referencia do carimbo de tempo; + _Veriicagéo criplogrfica da assinatura digital; lassificagao | Pagina PROJETO SREI: PA 1.9.5 — Requisitos para Software SREI vi2012 | LSFTEC:Restito | 29/71 rary 0888001Sree + Verficagao dos atributos da assinatura Caso 0 objeto de veriicaao do estado de revogagio no seja 0 ideal (da proxima publicago apés 0 instante de referéncia do carimbo de tempo) o sistema DEVE obte-lo e substitu, AD.AD.AS | Veriicago ue © sistema DEVE ser capaz de verificar os documentos assinados com mais de uma ‘mitipias assinatura digital (co-assinatura e contra-assinatura). assinaturas AD.AD.14 | Verificagio da O sistema DEVE ser capaz de apresentar ao operador todos os dados referentes de cada assinatura digital presente no documento. cvoncete No caso da presenca de mais que uma assinatura, deve informar a relacdo entre elas (co- assinatura e contra-assinatura). Para cada assinatura digital presente, DEVE ser capaz de informer: ‘+ Dados do certificado digital do signatério e de sua cadeia de certficacao, incluindo os campos especificos ICP-Brasil, + Dados do certiicado de atributo, quando presente; + Dados do carimbo de tempo: autoridade de carimbo de tempo e instante do carimbo de tempo; + Compromisso de assinatura; + Instante de assinatura alegado pelo signaléro(signingtime); + Outros atributos que forem relevantes. O sistema DEVE ser capaz de apresentar 20 operador o instante da assinatura alegado pelo signatario, instante do carimbo de tempo da assinatura e, quando for possivel extrair automaticamente, a data do documento assinado, a fim de que o operador possa avaliar a consistEncia destes instantes. ‘AD.AD.AS | Verifcagio da sistema DEVE informar quando a assinatura digital presente em um documento néo assinatura cobre 0 escopo de todo 0 documento. Neste caso, deve apresentar o trecho do documento digital: escopo coberto pela assinatura digital da assinatura Titulo “Versio | Classificacao | Pagina PROJETO SREI: PA 1.9. Requisitos para Software SREI vi2e12 | LS-TECRestrito | 30/71 ‘AlogAD.AD.16 | Verificago da assinatura digital: Resultado da verificagso ‘O sistema DEVE considerar os seguintes estados de resullado do procedimenio de validagao de uma assinatura digital: ‘= Valido: certificado valido; ‘+ Invalido: certificado invalido; + Indeterminado: quando no é possivel determinar se a assinatura std valida ou invalida, geralmente devido a falta de objetos (ex: LCR ou OCSP, certificado da cadeia, atributos obtigatérios, etc) ADAD.17 | Verificagéo da assinatura digital: recebimento de documentos No momento de recebimento de um documento assinado digitalmente extemo, o sistema DEVE: © Verificar a assinatura; ‘© Complementar a estrutura de atributos de forma que possa ficar aderente 4 estrutura de atributos AD-RC (ou AD-RV), incluindo: © Cettificados e cadeias de certificagao; © Carimbo de tempo da assinatura; © Objetos de veriicarao do estado de revogacao; 3.2.3 Carimbo de tempo Referéncia | Requisito ‘Origem Descrigéo morn lcenes a erper sistema DEVE Tequlter canbe de tego Ge aUonaGe Ge Crnbs d Tomo .ero1 | Crinbo de rosea dc? Se oa ae - Tea a aT We eo DEVE Ww VOTRE G WS COGSIOTS aocr.ca | Veitarée | RFC-sI61 teanturt io sanao arte tempo \eP-Brasit O cerificado de assinatura do carimbo de tempo DEVE: 2 Rerum cortient aes Titulo Versio | Classificagao | Pagina PROIETO SRE! PA 105~ vi2ei2 | LSHTECResito | 51/71 eats pee Soest Sel ‘Meg iy THe Sol 088e00Ie‘+ Possuir do pro2ésito de uso de chave (KeyPuposelD) “assinatura de carimbo de tempo" definide no extencied key usage como timestamping (1.3.6.1.5.5.7.3.8), ‘AD.CT.03 | Indisponibiidad e do servigo de carimbo de tempo. ro momento da geracdo de uma assinatura digital, caso nao seja possivel obier 0 carimbo de tempo de assinatura, 0 sistema DEVE: + Gerar anotacao de evento (log) As anotagées dos eventos DEVEM indicaro instante de inicio da incisponibilidade e o instante do término da indisponibilidade. + Caso 0 servigo de obtencao do carimbo de tempo fique indisponivel por mais que 24 horas, o sistema DEVE gerar uma notificagdo a corregedoria. + Assim que hower 0 retoino do servigo, o carimbo de tempo DEVE ser obtido e incluido na assinatura Referéncia | Requisito ‘Origem Descricdo AD.CA01 | Confguracto © sista DEVE permir a coniguagdo das fntes de auordege, para cada classe do dae totes do ova reap Spiiege fone de atria. autoridade O sistema DEVE possuir controles de seguranga que garantam a integridade e evite | alteragéo nao autorizada da relacao de fontes de autoridade ao.cac2 | Tratmenio de | RFOw2a1 O sistoma DEVE se capaz de vata certicado de aibuo, segundo a RF S231 cetiicado de + Veriicago de ariado de atrbuo, ncindo revogego '* —Geragdo de assinaturas com a incluindo certificado de atributo; + Vrcago de assinatua com presana de certicado de att. An.cacs | Delegagto de | RFC 3281 © sistema DEVE ter capaz de talardlegagdo de piviogio por meio de cenicado de Privilégio atributo, segundo a RFC 3261. No caso de delegario, todos os certiicados de atributo envolvidos devem ser incluldos na assinatura, [Versio | Classificagao | Pagina PROJETO SREI: Requisitos para Software SREI vi2ei2 | LSHTECRestrito | 32/71 “Nag oll “Sid Tiel O8S200 THELUTE WAU mas Tos akfene GeVe waldo liars eotaceie a sb uo aio ac pang cea certificado de | de cartério de registro de iméveis’ na assinatura final dos seguintes documentos: ‘aifibuto * Documentos emitidos aos solicitantes: (certidées, notas de exigéncias, etc); Tepe raal ect eiains 3.3 Modelo de dados Esta secao apresenta os requisitos relacionados ao modelo de dados do SRE, sendo divididos nas seguintes areas: * Imével e matricula; © Pessoa; © Pedido, 3.3.1 Imével e matricula Referéncia | Requisito Origem Descricao DAD.IM.01 Numero da © SREI DEVE identificar cada imével registrado (matricula) através do nimero da matticula maticula, © Némero da Matrcula DEVE ser regstrado no formato CCCCC-NNNNNNN-DD, sendo: + COCK = Cé«igo do Carrio; + NNNNNNN = Nimero sequencial da maticua (sequencial para cada carro); + _DD= Digito de Controle (caleulado sobre todos os campos anteriores) aie eT [/ Ghassifisagao | Pagina PROJETO SRE: PA 1.0.5 — LSLTEG:Restilo | 93/71 Requisitos para Sofware SREI "eS wu Sid Tiszye ol 08se00d© ndmero sequencial da matricula DEV ser um nimero Infero aliibuldo confinua e sequencialmente, com incrementos unitérios, a cada matricula registrada no cartéro, ‘A numeragao atribuida aos registros do SREI DEVE dar continuidade & numeraglo das matriculas previamente existentes em suporte papel ou, na auséncia destas, ser iniciada pelo niimero 01 (um). DAD.IM.02 | Nomero sequencial da matricula (0 ndmero sequencial da matricula (elemento NNNNNNN do numero da matricula) DEVE ‘ser um niimero inteiro atribuido continua e sequencialmente, com incrementos unitarios, a cada matricula registrada em cada cartério (elemento CCCCC). A numeracdo atribuida aos registros do SRE deve dar continuidade @ numeragio das matriculas previamente existentes em suporte papel ou, na auséncia destas, ser iniciada pelo niimero 1 (um). DAD.IM.03 | Algoritmo do digito ve cuntiuie uo 0 digito de controle do Ndmero da Matricula deve ser calculado ul . FUN.RT.05 © ssistema, para cada pagina de documento ou titulo apresentado em papel, no momento dda sua recepedo no atendimento, DEVE gerar 0 identificador da pagina, Retulo do ce O identificador da pagina DEVE possuir 0 seguinte formato: . pape! O sistema DEVE gerar um rétulo (etiqueta) com o identificador de pagina pata cada pagina do documento, para que seja colada em cada pagina do documento. FUN.RT.08 | Protocolo recepgao documentos && © protecolo de recepeio de documentos e titulos DEVE conter a quantidade dos documentos e titulos epresentados. [ Chassiicasto PROJETO SREI: PA 1.9.5— Requisitos para Software SREI vi2ri2 | LSITECRestito | 48/71 ou Sid “U O8S2001d seh3.4.4 Anélise do pedido - captura inicial Referéncia | Requisito ‘Origem Descrigao FUN.CLOt | Validagio de Os documentos e titulos no formato natodigtal recepcionados DEVEM ser validados documento (validagao da assinatura, poder do signatério, formato) antes de sua insergao no sistema natodigital do cartério, Fun.clo2 | Geracia ‘to Os documentos @ titulos em papel recopeionades DEVEM ocr igitalizados © exsinados representante digitalmente por um funcionéio do cartério igital (Asitaizacao) FUN.CLOS | Momento da ‘A gerago do representante digital (digitalizacao) DEVE ocorrer @ qualquer momento entre sgeragao do ‘a recepgao do pedido e a andlise do pedido. representante igttal FUN.CLO4 | Incluséo do © sistema do cartério DEVE inciuir na base de titulos e documentos os representantes representante na digits dos titulos e documentos associados ao pedido, mantendo a referéncia entre base de titulos & pedido e tais documentos. documentos as Versio. | Classificacao | Pagina PROJETO SRE: PA 1.9.5 — vi2d2 | LSHTECRestito | 46/71 Requistos para Software SREL TER SHE ol Osse0algFUN.CLOS [Formato do © formato do representante digital DEVE atender & norma vigente do comité gestor do | | representante SREI digital FUN.CLO8 | Assinatura do A assinatura digital do representante digital (arquivo digitaizado) DEVE atender & norma | © representante vigente do comité gestor do SREI digital FUN.CLO7 No momento da insercao de um documento eletrnico (seja natodigital ou representante | O digit) no sistema DEVEM ser gerados seus metadados. A relagao e formato dos metadados DEVE atender norma vigente do comité gestor do SREI Associago de mmetadados Dentre os metadados esti: + Tipo do documento; + Pedido associado; + Localizaglo fisica do documento em papel; FUN.CLO8 | Local ae Para cada representante digital, 0 sistema do cartério DEVE permir 0 cadastro e axibiego | 0 armazenamento do local de armazenamenio fisico do documento em papel, por meio das informagies fisico to presentes nos metadados associados. documento em Para os casos em que ocorrer a mudanga da localizagio fisica do documento em aapel, o papel sistema DEVE suporiar a alleragio dos respectivos metadados. Ses Titulo Versio Classificagéo | Pagina PROJETO SREI: PA 1.9.5 — vi2r12 | LSHTECRestito | 47/71 Requisits para Software SREL = usd ——————— neg eT Trsehe al OSS200dUVEL FUN.CLO9 | Veriicago dos | 0 sistema do cartorio DEVE verificar se foram gerados os representantes digitais de todos, doclienits ‘08 documentos relacionados ao pedido antes de inciar a etapa de anlise. digitalizados FUN.CL10 | Visualzagéo de 0 sistema do cartrio DEVE permit 20 funciondro visualizar todos os documentos e titulos documenios associados a um pedido, para que possa realizar sua analise. titulos FUNAP.11 | Cadasto de © sistema do cartério DEVE suportar 0 cadastramento de checklists para conferéncia de checklists de fipos de documentos. conterencia de No minimo, DEVE suportar 0 cadastro dos checklists de conferéncia de documentos documento definidos pelo Comité Gestor do SRE. FUNGI12 | Exibieso de O sistema DEVE ser capaz exibir 0 checklist de conferéncia de documento no momento de checklist, de ‘andlise de um documento ou titulo. conferéneia de documento FUN.CI13 | Extragio dos dados © sistema do cartério DEVE fornecer uma interface para a anolagio dos dados relevantes do documento Presentes em cada documento ou titulo associado a um pedido. FUN.CL14 | Identiicago dos. No inicio da fase de analise do pedido,o sistema do cartorio DEVE suportar aidentiicagao Iméveis das de todos os iméveis © pessoas contides em cada titulo, a fim de faciliar a verificagso do pessoas. contraditrio, [eee emo [Versio | Glassificagéo | Pagina | PROJETO SREI: PA 1.9.5— vi2012 | LSETEC:Restito | 48/71 Requisits para Software SREL ul Si FON ZAG ww 0882001FUN.CL15 | Anotagéo de divergéncia sistema do cartorio DEVE suportar a anotacao das divergéncias encontradas durante a anélise de um documento ou titulo. 3.4.5 Analise do pedido Referéncia | Requisito Origom Descrigao FUNAP.O Visualizapao das 0 sistema do cartério DEVE aisponibilizar, para os funcionérios responséveis pela andlise dos pedidos, para cada tipo de pedido (consulta, exame e célculo e registro), a visualicay.a0 filas de pedidos is da relago dos pedidos em andlise, ordenados por orciem de precedéncia (chegade), FUN.AP.02 © sistema do cartorio DEVE gerar os sequintes protétipos de documentos como resultado da fase de analise: = Pedido de registro: Geragio ae © Protétipe do ato ou protétipo do © Prototipo da nota de exigéncia. restitintio do patito) + Pedido de certidao: © Protétipo da certidao; * Pedido de exame e calculo: © Protétipo do ato (para uso interno futuro) e Protétipo nota de exame e célculo; ea anu “Versio [Ciassificagao | Pagina PROJETO SREI: PA 1.9.5 — Requisitos para Software SREI vi2r12 | LSETECRestito | 49/71 nag wW SI FOSr ye ol Osseo CCou (© Protétipo da nota de exigéncia. FUNAP.O3 | Assinatura do O sistema do cartério DEVE requisitar a assinatura do protétipo do resultado do pedido a0 prot6tipo do ‘operador do cartério responsével pela andlise do pedido. resultado do pedido 3.4.6 Verificagao do contraditério Referéncia | Req Origem Descricéo FUN.VC.01 © sistema do cartério DEVE suportar © processamento de contraditéio referente aos iméveis ou pessoas envolvidas no pedido nas primeiras etapas da andlise do pedido, : inctuindo Veriicar existéncia de contraditério + Pesquisa de existéncia de contraditério entre pedidos (contraditério de prenotago); + Pesquisa de existéncia de contraditrio entre pedido e livros eletrénicos; + Auxiliona pesquisa de contradtério entre padido e livros em papel. FUNVC.O2 | adores Rea! © sistema do cartério DEVE manter indicadores Real e Pessoal no formato eletrénico a jores Real Pbsacal coifonnats partir dos dados presentes nos livros em papel e nos livros de registro eletrnico imobitaro. eletronico A existéncia dos indicadores no formato eletrOnico @ fundamental para a operagao do z _Titulo | Versio | Classificagao | Pagina PROJETO SREI: PA 1.9.5 — Requisitos para Software SREI vi2r42 | LSETECRestito | 50/71 "NBS erp “ToRTy a 0888001dservigo de registro eletrénico imobiiério e, ambém, para que o SAEC possa drecionar © pedido ao cartério pertinente, FUN.VC.03 | Anotagées da andlise do pedido sistema do cartério DEVE disponibilizar a0 funcionério uma interface para possibiltar a inserpao de anotagées sobre o processo de andlise de um pedido, FUN.vC.04 | Verifieagdo de existencia de ccontraditorio no pedido de registro | No processamento do pediio de registiu, u sislerna Ue cart6rlo DEVE sempre verificar a existencia de contraditério eletrOnico. 3.4.7 Primeira qualificagéo eletrénica da matricula Referéncia_| Requisito Origem Descrigao FUN.1QE.01 | Primeira | 0 sistema do cartério DEVE fornecer funcionalidades para suportar a primeira qualificacao registros em pape! qualificagao eletronica da matricula letrénica FUN.1QE.02 | vigracao oe sistema do cartério DEVE suportar a migragéo para registro eletrénico das matriculas do proprio cartério ou de outra circunscri¢do oriundas de: ara registro + regisiro de matrcula de iével registrado no lvro 2; letrénico * livro de transcrigao; E Paulos eneran | Classificagao | Pagina PROJETO SREI: PA1.9.5— LSETEC:Restito | 51/71 Requistos para Software SREL Cor Tota, Pall 0889001, ag wu “Sig@B 150 Ec A analise da situacdo juridica da matricula em pedidos de registro somente DEVE ser FUN.1QE.03 processada a partir de dados proveniente dos livros eletrOnicos de matriculas. Por este eres motivo, a necessidade da realizagao da 1* qualificacéo eletrénica quando a matricula A gualicarto estiver em lvro de registro ou de transcrigao. eletronica © sistema do cartério DEVE prever mecanismos de controles que impecam o prosseguimento da operagéo em caso de necessidade de primeira qualficagao. FUNAQED | iz Quando da migragao de circunscricao, o sistema do cartério DEVE permit a abertura de ee 5 matricula eletrénica a partir da situacdo jurdica do im6vel extraida da certidéo de origem circunserigso do imove FUN.1QE.05 | Nota de exigéncia Na migragéo de circunscrico, o sistema do cartério DEVE suportar a emisséo de nota de na migrago de exigéncia para regularizagao da matricula de origem. crcunscrigfo FUN.1QE06 | Inclusao do No momento da 1 qualificagdo eletrénica de uma matricula, o sistema do cartério DEVE. representante requisitar @ incluso, na base de fitulos e documentos, dos representantes cigitais digital da maticula {arquivos Livro de trnscrigao: Geraeao de novo nlimero de matricula; * Migracao ce circunscri¢ao: Geracao de novo nimero de matricula FUN.1QE.08 | Confrmagio de encerramento da matricula ou transcrigao nos livros em papet (0 sistema do cartério DEVE requisitar ao operador uma confirmagao sobre a realizagao da ‘averbagiie do encerramento da ragisten na livre 2 nu na livre de transerigfa, para dar continuidade a0 proceso. Este evento DEVE ser registrado como um evento do sistema associado ao pedido de registro. FUN.10.09 | Velidagdes ‘automaticas Quando possivel, 0 sistema do cartério DEVE realizar velidagSes automaticas de consisténcia do pedido, como, por exemplo, CPF, CNUP, etc. 3.4.8 Qualificagao e analise Referéncia | Requisito Origem Descrigao. FUN.QE.01 (© sistema do cartirio DEVE disponibilizar ao operador 0 seguinte conjunto minimo de tease informagbes para andlise: disponiveis 20. © Ocorréncias de contraditério; pared, © Dados do pedido; ‘+ Titulo e documentos de suport, inciuindo os dados extraldos de tais documentos; Titulo “Wersdo [7 Ciassiteagio | Pagina PROJETO SRE: PA 1.0.5 — vi2ni2 | LS-TECRestite | 63/71 Requisitos para Software SRE! ‘Neg ou Sid TNaIS 0882001 a+ Matriculas envolvidas no pedido; + Resultado de consultas externas automaticas; © Andlises anteriores (notas de exigéncia emitidas, prototipos de atos elaborados, | protétipos de registro de matricula eletrOnica); + Anotagbas realizadas pelos operadores; FUN.QE.02 © sistema do cartério DEVE manter a base histérica do resultado das andlises sobre Histor d eine = ‘matricula eletrOnica (anotagbes, regularizagbes de valores, exame e célculo requistados andlses anteriores | anterior). FUN.QE03 | Rote de ( sistema do cartério DEVE suportar a configuragao de oteiros de qualifcagao e analise, qualificapo oe para auxiliar do procedimento de queliicagdo e andlise de pedido. andlse FUN.QE04 | Marcaggo de (© sistema do cartorio DEVE suportar a marcagéo de atvidades realizadas pelos alividades do operadores, referentes ao roteiro de qualificagdo e andlise. rotsiro realizadas FUN.QE.05 O sistema do cartorio DEVE permitr a configuracéio de modelos de atos estruturados pré- Modelos de alos Identificador do documento (e-ARQ Brasil, Numero do documento (e-ARQ Brasil) Namero do pedido (quando existir um namero de pedido associado). Localizagao fisica (somente quando for um representante digital). DE.10 Metadados para | NOBRADE (© SREI DEVE gerar metadados para os elementos de descrigéo arquivstica aderentes & descrigao normalizagao do comité gestor do SREI arquivistica Det Metadados ARQ | e-ARQ Brasil Conforme requisito estabelecido pelo e-ARQ Brasil, o SREI DEVE gerar metadados para {as seguintes entidades relacionadas a um documento digital © Documento; © Classe do documento: refere-se aos diversos niveis de agregago do plano de Classificagao (classes, subclasses, grupos e subgrupos) que s80 organizados de forma hierérquica, Evento de gestao; Agente; Componente digital; Evento de preservacao. oe Titulo E Versio. |) Classificagao. | Pagina PROJETO SREI: PA 1.9.5— vi2e12 | LSETEGRestito | 69/71 Requisitos para Software SRE} ud Eb. —————— ng THEE Wh 08880014Processo nf 24 28515 Fis. Pid 3_ Sev__— 4 Referéncias bibliograficas SBIS, 2009a -—-SBIS. Manual de Certificacdo para Sistemas de Registros Eletrénicos de Saiide (SRES). Sociedade Brasileira de Informatica em Satide (SBIS) e Conselho Federal de Medicina (CFM). Versao 3.3. S40 Paulo. 2009. SBIS, 2009b ‘BIS. Manual de Operacional de Ensaios e Analises para Sistemas de Registros Eletronicos de Satide (SRES). Sociedade Brasileira de Informética em Satide (SBIS) e Conselho Federal de Medicina (CFM). Versao 1.2. Séo Paulo. 2009. 1S, 2007 ABNT. NBR ISO/IEC 27002: Tecnologia da Informagéo — Técnicas de seguranga- Cédigo de pratica para gestéo da seguranga da informagao. Associagao Brasileira de Normas Técnicas (ABNT). Rio de Janeiro. 2007. OWASP, 2008 OWASP. Open Web Application Security Project Owasp Testing Guide. Version 3.0. 2008. MCTS, 2007 ICP-Brasil. Manual de Condutas Técnicas 5 (MCT 5) Materiais e documentos técnicos para homologagaéo de softwares de autenticaco no ambito da ICP-Brasil — Titulo PROJETO SREI: PA 1.9.5 ~ Requisitos para Software SRE! Versio Versao 1.1 release 12 Data da liberacdo 15/02/2011 Classificacdo LSI-TEC:Restrito Autores Gislaine Bueno, Volnys Bernal, Adriana Unger, Marcelo Silva Propriedade LSI-TEC e CNJ is Restri¢ées de acesso | LSI-TEC, CNJ e ARISPProceso n?_eF"* rs 10g o Serv___—- Volume |: Requisitos. ICP-Brasil. Verso 2.0. 2007. ICP-Brasil, 2010 Comité Gestor da ICP-Brasil. Estrutura normativa da ICP- Brasil. Verso 3.4. Brasilia, 2010. RFC 5280 Cooper, D; et. al. RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Internet Engineering Task Force (IETF). May 2008. UN, 2010 United Nations. Recommendation no. 37: digital evidence certification recommendation. Economic Commission for Europe - Economic and Social Council ~ United Nations. Feb. 2010. 31p. Titulo Versio | Classificagdo | Pagina PROJETO SREI: PA 1.9.5 — vi2rt2 | LS-TEC:Restito | 71/71 Requisitos para Software SREI