Projeto

Geral

Perfil

Ações
Histórico

Wiki » Arquitetura »

1.0 - Arquitetura de Software Geral

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.

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.

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.

4. Opções Arquiteturais

4.1 Gestão de Dados

[ A definir ]

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.

4.3 BPMS e BRMS

  • Red Hat JBoss BRMS & BPM Suite

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.

4.5 Portal

  • Zope Plone (Legado)
  • Joomla (Padrão)
  • PHP/Laravel (Exceção / Poucos Casos)

4.6 Gestão de Projetos

  • Redmine

4.7 SGBD

  • PostgreSQL
  • MySQL
  • MS SQL Server

4.8 Linguagens

  • Java
  • PHP
  • Python (Exceção / Poucos Casos)

4.9 Servidores de Aplicações

Backend

  • JBoss (Legado)
  • Spring Boot (Padrão Java)
  • Apache HTTP Server

Frontend

  • Nginx
  • Apache Tomcat

4.10 Geoprocessamento

  • OpenLayers
  • GeoWebCache
  • GeoNetwork
  • Hibernate Spatial
  • GeoServer
  • GeoTools
  • PostgreSQL + PostGIS

4.11 ETL

  • Talend
  • SQL Integration Services (SSIS)

4.12 BI

  • QlikView
  • Microsoft PowerBI
  • Pentaho

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.

4.14 PHP

  • Laravel
  • PHP Unit

4.15 JAVA

  • JHipster
    • Spring Boot
    • Angular
  • Maven

4.16 Conteinerização e Orquestração

  • Rancher
  • Docker
  • Kubernetes

4.17 Repositório Externo de Código

  • GitLab

4.18 Integração Contínua

  • Jenkins Server

Atualizado por Redmine Admin há aproximadamente 6 anos · 1 revisões