Processo de Entrega de Soluções

h1. 1.0 - Arquitetura de Software Geral

h2. 1.	Introdução

Este documento contém o conjunto das opções tecnológicas e das melhores práticas arquiteturais que devem ser adotadas na disponibilização de soluções de tecnologia da informação no Ministério do Planejamento, Desenvolvimento e Gestão.

h2. 2.	Definições, Acrônimos e Abreviações

AM – API Manager.

BPMS – Business Process Management System

BRMS – Business Rules Management System 

CPU – Central Processing Unit ou Unidade Central de Processamento. 

EJB – Enterprise Java Bean.

ESB – Enterprise Service Bus.

IS – Identity Server.

JAX.WS – Java API para XML Web Services.

JAX.RS – Java API para RESTful Web Services. 

JEE – Java Enterprise Edition.

JPA – Java Persistence API.

JSF – Java Server Faces.

JSP – Java Server Pages.

JSON - JavaSript Object Notation

MP – Ministério do Planejamento, Orçamento e Gestão.

POJO – Plain Old Java Object.

REST – Representational State Transfer. 

SGBD – Sistema Gerenciador de Banco de Dados

SOA – Service Oriented Architecture ou Arquitetura Orientada a Serviços.

SOAP – Simple Object Access Protocol.

SSO – Single Sign-On. 

XML – eXtensible Markup Language.

h2. 3.	Estratégia Arquitetural

A estratégia arquitetural adotada pelo MP é baseada no modelo orientado a serviços, ou SOA, que possibilita publicar componentes como serviços que podem ser acessados por clientes, independentemente da linguagem, plataforma ou sistema operacional, por meio do uso de padrões abertos, tais como Web Services, REST, SOAP e XML. 

h2. 4.	Opções Arquiteturais

h3. 4.1	Gestão de Dados

> [ A definir ]

h3. 4.2	Gestão de Acessos e Identidades

* _Acessos MP_

** Provê a interface de autorização permitindo a um usuário acessar a aplicação sob determinado perfil com permissões pré-definidas.

* _WSO2 Identity Server_ 

** Provê uma interface de autenticação única (SSO) entre um usuário e os sistemas acessados. Com a utilização de um IS, é possível federar bases de usuários para prover um acesso único ao usuário para todos os sistemas que este acessa. 

h3. 4.3	BPMS e BRMS

* Red Hat JBoss BRMS & BPM Suite

h3. 4.4	Barramento de Serviços

* O MPDG criou uma aplicação denominada ConectaGov que atua sobre o _backend_ da plataforma WSO2 (ESB + AM) para prover um barramento de serviços para as aplicações e sistemas do Executivo Federal.

* O catálogo de serviços pode ser acessado pelo link *_https://catalogo.conecta.gov.br/conectagov/_*

h3. 4.5	Portal

* Zope Plone (Legado)

* Joomla (Padrão)

* PHP/Laravel (Exceção / Poucos Casos)

h3. 4.6	Gestão de Projetos

* Redmine

h3. 4.7	SGBD

* PostgreSQL

* MySQL

* MS SQL Server

h3. 4.8	Linguagens

* Java

* PHP

* Python (Exceção / Poucos Casos)

h3. 4.9	Servidores de Aplicações

*Backend*

* JBoss (Legado)

* Spring Boot (Padrão Java)

* Apache HTTP Server

*Frontend*

* Nginx

* Apache Tomcat

h3. 4.10 Geoprocessamento

* OpenLayers

* GeoWebCache

* GeoNetwork

* Hibernate Spatial

* GeoServer

* GeoTools

* PostgreSQL + PostGIS

h3. 4.11 ETL

* Talend

* SQL Integration Services (SSIS)

h3. 4.12 BI

* QlikView

* Microsoft PowerBI

* Pentaho

h3. 4.13 Segurança

* A aplicação deve implementar criptografia não reversível para senhas gravadas em bancos de dados; 

* A aplicação deve proteger credenciais de acesso pelo uso de conexões SSL com criptografia forte nos processos de login;

* Se a aplicação trafegar dados sensíveis pela Internet, devem ser usadas conexões SSL com criptografia forte;

* A aplicação deve registrar todas as atividades dos usuários e manter esses logs por um período mínimo de xx meses;

* A aplicação deve se proteger de Cross-Site Scripting (XSS) por meio da validação e higienização dos dados recebidos dos usuários antes de processá-los ou exibi-los de volta no servidor web;

* A aplicação deve implementar proteção contra SQL Injection, não permitindo entrada de dados diretamente em queries SQL (ver mais informações em https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet);

* A aplicação deve gerenciar cookies e tokens de sessão de forma segura para proteger os identificadores de sessão dos usuários:

** Todos os cookies devem ser marcados como HTTPOnly para impedir que acesso via JavaScript tente transmiti-los a terceiros;

** Os cookies utilizados como parte de transações de ordem financeira para manter o estado da sessão devem ser marcados como "seguros" para evitar a transmissão através de conexões não-SSL;

** Invalide tokens de sessão apropriadamente após um tempo razoável de inatividade.

* A aplicação deve remover as informações sensíveis de parâmetros GET passados via URL porque podem ser registradas e armazenadas em vários locais, tais como logs de auditoria, históricos de browsers etc.;

* A aplicação deve garantir que sua resposta durante o processo de login é neutra: não deve ser possível identificar o dado incorreto, se é o identificador do usuário, a senha ou algum outro dado requerido. Não deve ser possível identificar se o usuário e a senha são válidos a partir da resposta da aplicação;

* Todos os dados informados pelo usuário e parâmetros devem ser validados e qualquer caráter ilegal removido antes de ser processado.

h3. 4.14 PHP

* Laravel

* PHP Unit

h3. 4.15 JAVA

* JHipster

** Spring Boot 

** Angular

* Maven

h3. 4.16 Conteinerização e Orquestração

* Rancher

* Docker

* Kubernetes

h3. 4.17 Repositório Externo de Código

* GitLab

h3. 4.18 Integração Contínua

* Jenkins Server