Autor
Formação em engenharia de produção
(Poli-USP), atuando desde 1977 em análise,
arquitetura, desenvolvimento, programação, implantação e gestão de sistemas
(software, hardware, infraestrutura), dos jurássicos mainframes Burroughs &
IBM, aos mais recentes dispositivos computacionais, com expertise teórica e
prática em Sistemas Operacionais [ MS-DOS 2.0 ~ 4.1, PC-MOS/386, IBM OS/2,
Windows 3.1 ~ 11, Linux, Android, Chrome OS ], Linguagens e Ambientes de
Programação e Desenvolvimento [ Assemblers Z80, 8086, 8088, i286 ~ i486, AMD k5
~ Ryzen, Moto68000, Intel Core® i3 ~ i9, Fortran, Cobol, Algol, HTML, php,
inúmeros RDBMS, MS.SQL Server,
ApacheWebServer, C, C++, C#, MS.Visual Studio, MS.NET, ASP, Python, Java,
JavaScript, e outras in between
].
Conteúdo
1. Objetivos
2. A quem se
destina
3. Texto didático e
simples sobre Dispositivos Computacionais e Software
3.1. O que são
Dispositivos Computacionais?
Exemplos
3.2. Elementos em
comum
3.2.1. Camada dos
softwares Aplicativos
Como se produz um
Aplicativo
A - Produção do
Código-Fonte
A.1. Exemplo de Código-Fonte bastante tosco
A.2. Código-Fonte
pode conter atividades maliciosas?
A.3. Rotinas
Externas podem conter atividades maliciosas?
B - Compilação e
Linkagem do Código-Fonte
B.1 - Compilação do
Aplicativo
B.2 - Linkagem do
Aplicativo
B.3. Linkagem das
Rotinas Externas
B.4. Scripts de
Compilação e Linkagem podem conter atividades
maliciosas?
C – Carga do
Programa Executável
C.1. Carga de
Programa Executável pode ensejar atividades
maliciosas?
3.2.2. Camada do
Sistema Operacional
3.2.2.1. Exemplos
de sistemas operacionais bem conhecidos
3.2.2.2. Sistemas
Operacionais podem conter atividades maliciosas?
3.2.3. Camada de
Hardware
3.2.3.1. Exemplos
de elementos de hardware
3.2.3.2. Firmware –
Chips contendo software
3.2.3.3. Firmware
pode conter atividades maliciosas?
4. Tornando este
tema mais interessante
4.1. Imaginando um
conjunto de necessidades a serem atendidas por um
Aplicativo
4.2. Solução
proposta por um Aplicativo Fruticrático
4.3. Divagando
sobre atividades maliciosas no Aplicativo Fruticrático
4.3.1. Imaginando
motivos para atividades maliciosas
4.3.2. Imaginando a
concretização de uma atividade maliciosa
4.3.3. Tentando
constatar uma atividade maliciosa
4.3.3.1.
Constatando por meio de testes práticos
4.3.3.2.
Constatando por análise de software
4.3.3.3.
Constatando por outras análises
5. Sistemas Computacionais
6. Sistemas Computacionais de Missão
Crítica
7. Requisitos
Mínimos para Validação de Confiabilidade de Sistemas
Computacionais
Homologação
8.
Conclusões?
1. Objetivos
- Apresentar didaticamente explanações
extremamente simplificadas sobre Dispositivos Computacionais e seus
Aplicativos, quando utilizados no âmbito de um Sistema Computacional
(doravante, simplesmente por
"Sistema" – v. definição no item
5.).
- Proporcionar um entendimento básico dos
atributos de precisão, segurança, confiabilidade e lisura (doravante, simplesmente
"Confiabilidade") de Aplicativos e Sistemas, bem como de seu
processo de utilização para qualquer finalidade
específica.
- Proporcionar um entendimento básico da
relevância de cada elemento físico e lógico de Aplicativos e Sistemas, para
a efetividade dos mencionados atributos de
Confiabilidade.
2. A quem se
destina
- Ao
público em geral, leigo em Tecnologia da Informação, interessado em aprender,
compreender e formar opinião independente sobre os aspectos de Confiabilidade
de Aplicativos e Sistemas.
3. Texto didático e simples sobre
Dispositivos Computacionais e Software
3.1. O que são Dispositivos
Computacionais?
Consideremos apenas tipos de Dispositivos
Computacionais mais conhecidos, que trataremos simplesmente por
"Dispositivos".
Exemplos
·
Smartphones
·
Tablets
·
Notebooks
·
Computadores desktop
·
Caixas eletrônicos
·
Terminais de consulta (em shoppings, por
exemplo)
·
Terminais de apostas
lotéricas
·
Terminais para pesquisa de preferências ou
satisfação dos Clientes
3.2. Elementos em comum
Todos
estes Dispositivos possuem elementos em comum, que podemos
simplificadamente considerar como "camadas":
1.
Camada dos softwares
Aplicativos
2.
Camada do Sistema
Operacional
3.
Camada de Hardware
Vejamos mais detalhadamente cada uma
destas camadas...
3.2.1. Camada dos softwares
Aplicativos
Em
essência, esta camada contém os programas de computador através dos quais
os usuários interagem com os Dispositivos.
Exemplos
de softwares Aplicativos:
o
Assistentes pessoais
o
Editores de textos
o
Planilhas de cálculo
o
Aplicativos contábeis
o
Aplicativos comerciais
o
Aplicativos de IRPF, IRPJ e
correlatos
o
Softwares para pesquisa de preferências ou
satisfação dos Clientes
Como se produz um
Aplicativo
Lembrando que estamos tratando de programas
(softwares) destinados a dispositivos comuns, como os já mencionados, podemos
dizer que, da fase de produção à fase de utilização, todo software passa
por estas
etapas:
A - Produção do
Código-Fonte
B - Compilação do
Código-Fonte
C – Carga do Programa Executável
Precisaremos detalhar de forma simples as
três etapas deste processo, para compreendermos que
todos os elementos envolvidos são de extrema relevância para a Confiabilidade de
um Sistema.
A - Produção do
Código-Fonte
Utilizando linguagens de programação (p.ex.,
Phyton, C, C++ etc.), programadores escrevem o Código-Fonte, basicamente um
conjunto de arquivos de
texto contendo seqüências lógicas de instruções a serem
executadas pelo Dispositivo (lembrando: smartphone, tablet, notebook,
terminais de serviços etc.
Apenas
para oferecer uma visão breve e simples do conteúdo lógico de um
Código-Fonte, vejamos um Aplicativo hipotético, escrito com a também hipotética
linguagem de programação "TodoMundoEntende".
Nota
Na
verdade, se usássemos uma linguagem de programação real, cada linha deste
Aplicativo hipotético corresponderia a um conjunto de linhas de difícil
leitura por pessoas leigas em programação.
Por
exemplo, na linguagem de programação C++, a linha 1 do nosso Aplicativo seria
escrita assim:
clrscr()
#include
<iostream>
using namespace std;
int main() {
cout
<< "Quais os seus números da sorte hoje?";
return
0;
}
A.1. Exemplo de Código-Fonte bastante
tosco
Aplicativo Números da
Sorte |
1.
Limpa a tela e escreve:
Quais os seus números da sorte hoje? |
2.
Aguarda alguém tocar na
tela. |
3.
Chama a Rotina Externa [Teclado
Numérico]. |
4.
Escreve: Quantos números de
1 a 100 você deseja sortear? |
5.
Aguarda o usuário digitar um
número.
- Se número digitado = zero,
volta ao passo 1.
- Se número digitado =
100
- Escreve: "Não é
necessário sortear!"
- Aguarda 5
segundos
- Volta ao passo
1
- Se número digitado estiver
entre 1 e 99, prossegue...
- Se nada for digitado,
aguarda 10 segundos e retorna ao passo 1.
|
6.
Cria a variável [Quantidade]
- Memoriza a quantidade de
números desejada.
|
7.
Desenha grid de tamanho adequado à
quantidade de números.
|
8.
Cria o arquivo [Já
Sorteados] para armazenar os números gerados.
|
9.
Cria a variável [Contador],
para um contador de números gerados.
- Inicializa a variável
[Contador] com o valor zero.
|
10.
Chama a Rotina Externa [Gera Número
Aleatório]
- Recebe em retorno um
número gerado.
|
11.
Verifica se o número gerado
já está no arquivo [Já Sorteados].
- Em caso positivo, gerou um
número repetido...
- Em caso
negativo
- Armazena o número gerado
no arquivo [Já Sorteados]
- Prossegue...
|
12.
Exibe o número aleatório
gerado, em uma posição livre do grid.
|
13.
Incrementa o valor da
variável [Contador]
- (Contador = Contador +
1).
|
14.
Verifica se já gerou a
quantidade de números desejados
- Se [Contador] <
[Quantidade]
- Continuar gerando
números >>> Retorna ao passo
10.
- Se [Contador] =
[Quantidade]
- Já gerou os números
desejados >>> Prossegue...
|
15.
Exibe os botões [Imprimir] e
[Encerrar]
- Botão
[Encerrar]
- Prossegue para o passo
16
- Botão
[Imprimir]
- Imprime o grid contendo os números
sorteados.
- Exemplo, para um usuário
que solicitou 18 números:
15 |
27 |
17 |
01 |
45 |
03 |
25 |
55 |
56 |
99 |
08 |
02 |
20 |
60 |
07 |
23 |
05 |
98 |
- Prossegue para o passo
16.
- Se nenhum botão for
pressionado em 30 segundos...
- Prossegue para o passo
16.
|
16.
Encerramento
- Apaga a variável
[Contador].
- Apaga a variável
[Quantidade].
- Apaga o arquivo [Já
Sorteados].
- Retorna ao passo
1
|
No link abaixo, implementei uma versão deste Aplicativo, adaptada para ser executada em uma guia do navegador (programada com HTML e JavaScript).
• Para usá-la mais de uma vez, recarregue a página do Aplicativo.
• Para voltar a este artigo, feche a guia do Aplicativo.
App – Números da sorte
A.2. Código-Fonte pode conter
atividades maliciosas?
Qualquer
atividade maliciosa pode ser programada direta e explicitamente no Código-Fonte
do chamado Programa Principal de um software.
Programa Principal (como
aquele apresentado em A.1) é aquele que determina a sequência
lógica principal das atividades de um Aplicativo, recorrendo a chamadas a
Rotinas Externas para realizar atividades subsidiárias.
Entretanto, identificar trechos de códigos
potencialmente maliciosos não é tarefa trivial, principalmente devido a fatores
como:
·
A baixa legibilidade de determinadas linguagens de
programação, mesmo para profissionais da área.
·
A extensão do Código-Fonte examinado, que pode
chegar a milhões de linhas de código (linhas de texto contendo instruções), em
determinados sistemas.
·
O possível uso de técnicas de mascaramento adotadas
pelos eventuais "desenvolvedores maliciosos", incluindo a inserção de bugs (erros de lógica) para
"despistamento".
Empreitadas deste tipo exigem profissionais de TI
extremamente capacitados, utilizando ferramentas (softwares) de análises
estática e dinâmica, durante o tempo que se faça necessário para adquirir
entendimento pleno de todos os aspectos do funcionamento do Código-Fonte
examinado.
Ferramenta de análise estática:
analisa simplesmente o texto e a lógica do
Código-Fonte.
Ferramenta de análise dinâmica: dentre
inúmeras outras funções, analisa o Código-Fonte do Aplicativo durante a sua
execução, mostrando simultaneamente cada linha de código que estiver sendo
executada.
A.3. Rotinas Externas podem conter
atividades maliciosas?
Notemos
que o nosso Código-Fonte bastante tosco chama as rotinas
externas [Teclado Numérico] e [Gera Número Aleatório], as quais, neste caso,
devem executar as tarefas definidas pelos seus nomes.
Todavia,
cada Rotina Externa é, na verdade, um outro Programa de Computador, com o seu
próprio Código-Fonte, seu próprio processo de Compilação etc.
Portanto, mesmo sendo (em geral) dedicadas a
atividades específicas, subsidiárias ao Programa Principal do Aplicativo, as
Rotinas-Externas podem, sim, incluir atividades maliciosas nos seus
Códigos-Fonte.
B - Compilação e Linkagem do
Código-Fonte
Para que
o Dispositivo (smartphone, tablet, notebook, terminal de serviços etc.) possa
"entender" e executar as instruções do Código-Fonte do Aplicativo, é
necessário transformar esse Código-Fonte (um simples arquivo de texto) em um
Programa Executável.
Este
processo de transformação ocorre (usualmente) em 2
etapas:
·
Compilação
·
Linkagem
B.1 - Compilação do
Aplicativo
Esta
primeira etapa consiste em "entregar" o Código-Fonte (arquivo de texto aqui
denominado "Aplicativo.txt") a um Compilador específico para a linguagem
de programação usada.
Compilador - é um
programa de computador capaz de ler as instruções (textuais) do Código-Fonte e
traduzi-las para uma linguagem binária compatível com a máquina
(Dispositivo).
Durante
este processo, para traduzir o Código-Fonte do Aplicativo.txt, o Compilador
obedece a uma sequência definida por um Script de Compilação (um conjunto de
instruções textuais, também produzido pelos desenvolvedores do
Aplicativo).
Nosso
Aplicativo.txt transforma-se então em um arquivo escrito em linguagem binária,
que batizaremos como Aplicativo.bin (o sufixo do nome de arquivo varia muito,
mas utilizaremos "bin" para facilidade de
identificação).
Este
arquivo Aplicativo.bin contém as instruções originais do Código-Fonte, agora
traduzidas para linguagem binária, algo que, entretanto, ainda não é um
programa que possa ser executado pela máquina
(Dispositivo).
Lembrando que isto é uma simplificação
da simplificação...
B.2 - Linkagem do
Aplicativo
Este é o
segundo passo para a transformação do Código-Fonte em Programa
Executável.
Para que
a máquina (Dispositivo) possa executar as instruções traduzidas em linguagem
binária, contidas no arquivo Aplicativo.bin, é necessário transformá-lo em um
Programa Executável.
Basicamente, "entrega-se" o arquivo binário
Aplicativo.bin a um Linker.
Linker - é um
programa de computador capaz de ler as instruções binárias do arquivo
Aplicativo.bin e construir o Programa Executável
Aplicativo.exe.
B.3. Linkagem das Rotinas
Externas
Durante
o processo de Linkagem (construção do Programa Executável), o Linker obedece a
um Script de Linkagem (outro conjunto de instruções textuais, também produzido
pelos desenvolvedores do Aplicativo) para organizar e interconectar as
instruções binárias do Aplicativo.bin, bem como incorporar e conectar, onde
necessário, as Rotinas Externas eventualmente "chamadas" pelo
Código-Fonte.
No
momento da Linkagem, tais Rotinas Externas (que podem ter sido desenvolvidas por
terceiros, ou pelos próprios programadores do Aplicativo) precisam já
estar presentes no ambiente de Compilação e Linkagem, ou ser trazidas
de um ambiente externo para o ambiente de Compilação e
Linkagem
(via Internet, por
exemplo).
Neste
nosso exemplo, durante a construção do executável Aplicativo.exe, o Linker
procurará os arquivos binários (bin) das Rotinas Externas:
·
[Teclado Numérico]
·
[Gera Número Aleatório]
B.4. Scripts de Compilação e Linkagem
podem conter atividades maliciosas?
Sim!
Bastaria
que, ao construir o Programa Executável do Aplicativo, um desses Scripts
incorporasse, por exemplo, uma Rotina Externa maliciosa ou um segmento de
código-fonte malicioso, similar àqueles que veremos no item
4.3.
C – Carga do Programa Executável
O
Aplicativo, sob a forma de Programa Executável, será carregado (gravado) e
utilizado no Dispositivo (neste nosso exemplo, um hipotético Terminal de
serviços).
C.1. Carga de Programa Executável pode
ensejar atividades maliciosas?
Cabe
enfatizar que, se compilarmos duas versões "parecidas" do mesmo Código-Fonte
(por exemplo, uma delas com e outra sem um determinado trecho de Código-Fonte), não
teremos como descobrir "quem é quem" simplesmente examinando os respectivos
Programas Executáveis.
Sim,
existem ferramentas e procedimentos de descompilação, para se chegar ao
Código-Fonte original de determinado Programa
Executável.
Todavia,
comparar o Código-Fonte assim obtido e o Código-Fonte supostamente original é um
processo trabalhoso e complexo, que nem sempre resulta em conclusões
inequívocas.
Assim,
faz-se indispensável ter certeza de que o Programa Executável carregado
no Dispositivo seja exatamente aquele cujo processo de produção tenha
sido completamente monitorado e aprovado (Código-Fonte, Rotinas Externas,
Compilação, Linkagem e respectivos Scripts).
Evidentemente, podemos também conceber testes de
funcionamento dos Programas Executáveis supostamente diferentes, objetivando
detectar diferenças de comportamento sob as mesmas condições de uso,
tarefa esta também complexa e que nem sempre resulta em conclusões
inequívocas.
3.2.2. Camada do Sistema
Operacional
3.2.2.1. Exemplos de sistemas
operacionais bem conhecidos
o
Windows
o
Android
o
iOS
o
Unix
o
Linux
O
Sistema Operacional compreende um enorme e complexo conjunto de elementos de
software responsáveis por operar a parte física do Dispositivo e prover ao
Aplicativo todos os recursos físicos e lógicos de que precise para
funcionar.
(Lembrando, estamos exemplificando com apenas um
Aplicativo).
Constitui-se de uma infinidade de programas
gerenciadores e controladores de cada recurso físico e lógico existente no Dispositivo, incluindo também (por
exemplo) o conjunto de interfaces de vídeo, áudio, entrada e saída de dados por
dispositivos como teclados, digitalizadores, câmeras, displays etc. etc. etc.
3.2.2.2. Sistemas Operacionais podem
conter atividades maliciosas?
Pelo
fato de ser a camada "sobre a qual" o Aplicativo "roda" (funciona) e da qual o
Aplicativo depende para obter acesso aos recursos físicos e lógicos de que
necessite, o Sistema Operacional detém o poder de
realizar qualquer coisa, quer solicitada pelo Aplicativo, quer totalmente
à revelia do Aplicativo.
Sim,
diversas linguagens de programação possuem a capacidade de acessar diretamente o
Hardware, mas isto não elimina o mencionado "poder" do Sistema
Operacional.
3.2.3. Camada de
Hardware
Constitui-se de todos os elementos físicos (e
elementos lógicos associados) existentes no
Dispositivo.
3.2.3.1. Exemplos de elementos de
hardware
·
Placa-mãe
·
Processador (CPU)
·
Chips de Firmware,
incluindo:
o
BIOS
o
Relógio de Tempo Real
(RTC)
o
Chips de segurança proprietários
o
Chips geradores de números
aleatórios
·
Chipset (eventualmente incluído na classe de
firmware)
·
Memória de trabalho (RAM)
·
Memórias de armazenamento interno (HDD, SSD &
outras)
·
Memórias externas (flash drives, cartões
etc.)
·
Interfaces de comunicação (Ethernet, Wi-Fi,
Bluetooth, Firewire, USB etc.)
·
Interfaces de entrada e saída, como teclado, mouse,
touchpad, touchscreen, leitor de digitais, câmera, display, áudio, terminais de
vários tipos etc.
·
Fonte de alimentação, bateria
etc.
3.2.3.2. Firmware – Chips contendo
software
A camada
de Hardware incorpora também chips regraváveis
contendo softwares de controle e gerenciamento denominados Firmware,
significando que todo e qualquer Firmware presente no dispositivo deverá ser
plenamente conhecido e estar sob absoluto controle dos gestores de um Sistema
Computacional.
3.2.3.3. Firmware pode conter
atividades maliciosas?
Códigos
maliciosos eventualmente inseridos em componentes de Firmware seriam capazes
de executar quaisquer atividades insuspeitadas, de forma imperceptível e à revelia dos Aplicativos e do próprio Sistema
Operacional.
4. Tornando este tema mais
interessante
4.1. Imaginando um conjunto de
necessidades a serem atendidas por um Aplicativo
·
Uma Rede de Centrais de Abastecimento Regionais
pretende otimizar as compras e o fornecimento de frutas para os comerciantes que
as revendem aos Clientes.
·
Um Aplicativo de pesquisa irá monitorar diariamente
a preferência dos Clientes por determinadas frutas.
·
O Aplicativo será utilizado em milhares de
Terminais de Pesquisa (Dispositivos) instalados em sacolões e setores de
hortifruti de supermercados, por todo o país.
·
Cada estabelecimento ou comerciante possuirá
somente um Terminal.
·
Como a preferência do Cliente poderá depender da
oferta de frutas encontrada em cada estabelecimento, decidiu-se que um mesmo
Cliente poderá votar mais de uma vez por dia em estabelecimentos diferentes, mas
não em um mesmo estabelecimento.
·
Todos os Terminais serão idênticos, consistindo
basicamente de um computador simples, dotado de touchscreen (tela sensível ao
toque), áudio, conexão com a Internet, Relógio de Tempo Real sincronizado pela
Internet, Número de Identificação do Terminal (ID) gravado em firmware, botão
liga/desliga, botão de reset embutido.
·
Em cada região, todos os Terminais enviarão
diariamente os seus resultados a um computador instalado na respectiva Central
de Abastecimento Regional, o qual totalizará os dados e emitirá relatórios para
gestão de compras e fornecimentos de frutas.
·
Os computadores das Centrais de Abastecimento
Regionais enviarão diariamente as suas totalizações aos computadores da
Administração da Rede, onde trabalham os Gestores da
Rede.
4.2. Solução proposta por um
Aplicativo Fruticrático
Este
seria o Código-Fonte escrito com a hipotética linguagem de programação "TodoMundoEntende".
Relembrando a Nota
já apresentada em 3.2.1 - A
Na verdade, se usássemos uma
linguagem de programação real, cada linha deste Aplicativo hipotético
corresponderia a um conjunto de linhas de difícil leitura por pessoas
leigas em programação.
Aplicativo
Fruticrático |
|
1.
Terminal ligado e
inicializado.
|
2.
Aplicativo
inicializado.
- Obtém o ID do Terminal,
gravado em Firmware ( Exemplo: 61812145
)
- Obtém a Localização do
Terminal (consulta uma Tabela de
Localizações)
- Cria novo arquivo
[Registro de Preferências]
- Nome do arquivo =
Número do Terminal-Data-Pref
- Exemplo:
61812145-02102022-Pref
- Cria novo arquivo [Log
de Terminal]
- Nome do arquivo =
Número do Terminal-Data-Log
- Exemplo:
61812145-02102022-Log
- [Log de Terminal] –
Registra "Início de funcionamento" + data +
hora
|
3.
Verifica se o Terminal foi
desligado corretamente (v. passo 16)
- Se não encontrar o
sinalizador de desligamento correto (SDC)
- Ocorreu um
Reset
- [Log de Terminal] -
Registra a ocorrência de Reset no dia
anterior.
- Se encontrar o
sinalizador de desligamento correto (SDC)
- Não ocorreu um
Reset
- [Log de Terminal] -
Registra desligamento correto no dia
anterior.
- Deleta o arquivo
SDC
|
4.
Teste de
Terminal
- Exibe os botões [Uso normal] e [Testar
Terminal]
- Se pressionar [Testar
Terminal]
- [Log de Terminal] –
Registra "Terminal
teste - início+data+hora"
- Botão [Encerrar teste]
permanece disponível na base da tela.
- Terminal opera
normalmente, até que se pressione [Encerrar
teste].
- A qualquer momento, se
[Encerrar teste] for pressionado:
- [Log de Terminal] –
Registra "Terminal teste - fim+data+hora"
- Vai para o passo 12
- Encerramento diário – Execução
- Se pressionar [Uso
normal]
- [Log de Terminal] –
Registra "Terminal uso
normal+data+hora"
- Remove os botões [Uso
normal]
e
[Testar Terminal]
|
5.
Tela
Inicial
- Limpa a
tela
- Exibe a imagem de uma
cesta de frutas
- Escreve "Qual a sua
fruta preferida?"
- Escreve "Toque na tela
para iniciar."
- Aguarda alguém tocar na
tela.
|
6.
A partir deste passo, o
botão [Sair] permanece disponível na base da
tela.
- A qualquer momento, se o
Cliente pressionar [Sair]:
- Registra este evento
no [Log de Terminal]
- Interrompe o processo
- Volta para a Tela
Inicial – passo 5
|
7.
Identificação do Cliente
- 7.1. Chama a Rotina Externa [Teclado Numérico]
- 7.2. Escreve: "Informe o
seu CPF"
- 7.3. Chama a Rotina Externa [Valida
CPF]
- Informa "CPF inválido.
Por favor, tente novamente"
- Limpa o campo CPF +
aguarda 3 segundos + volta ao passo
7.2
- Prossegue para o
próximo passo
|
8.
Verifica se Cliente já
participou da pesquisa (neste estabelecimento, nesta
data).
- Consulta o arquivo
[Registro de Preferências], pelo CPF do
Cliente
o
Escreve "Você já
participou hoje. Gratos pela colaboração!"
o
Aguarda 10 segundos e volta para a Tela Inicial –
passo 5
o
Prossegue para o próximo
passo
|
9.
Seleção da fruta
preferida
- Cria a variável
[Preferência atual]
- Exibe uma scrollable list (lista suspensa)
em ordem alfabética.
Selecione a
sua fruta preferida.
Sua Preferência
|
Número |
Abacate |
01 |
Abacaxi
|
02 |
Ameixa |
03 |
Banana
|
04 |
Goiaba |
05 |
Laranja |
06 |
Maçã
|
07 |
Mamão
|
... |
Melancia |
.... |
Melão
|
... |
Morango |
... |
Pêra |
... |
... |
... |
- O Cliente deverá
rolar a lista de seleção e
tocar no nome da fruta selecionada.
- Destaca o nome da
fruta, na lista de seleção.
- Exibe os botões
[Confirma] e [Corrige]
- Grava nome e número
da fruta, na variável [Preferência atual]
- Exemplo: Ameixa 03
- Prossegue para o
passo 10.
- Se pressionar
[Corrige]
- Volta para a
rolagem da lista de
seleção.
- Se não pressionar nem
[Confirma], nem [Corrige]
- Aguarda 60
segundos
- Grava preferência em
branco, na variável [Preferência atual]
- Prossegue para o
passo 10.
- Se não selecionar uma
fruta e parou a rolagem da lista de
seleção.
- Aguarda 60
segundos
- Grava preferência em
branco, na variável [Preferência atual]
- Prossegue para o
passo 10.
|
10.
Gravação da preferência do
Cliente
- [Registro de
Preferências] - grava os seguintes dados:
- CPF do
Cliente
- Data e hora da
participação
- Nome e número da fruta
escolhida, contidos em [Preferência
Atual]
- Apaga a variável
[Preferência atual]
- [Log de Terminal] -
Registra evento "Cliente participou"
- inclusive para
preferência em branco
- Chama a Rotina Externa
[Musiquinha]
- Escreve: "Agradecemos
pela sua participação!"
|
11.
Encerramento Diário –
Verificação
- Verifica a data e o
horário
- Se não chegou o
momento de encerrar
- Volta para a Tela
Inicial – passo 5
- Se já chegou o momento
de encerrar
- Prossegue para o
próximo passo.
|
12.
Encerramento Diário –
Execução
- Limpa a tela e escreve
"Encerrando...
Aguarde..."
- [Log de Terminal] –
Registra data e hora do encerramento.
- Chama a Rotina Externa [Processa Preferências]
o
Processa o [Registro de
Preferências]
·
arquivo de exemplo:
61812145-02102022-Pref
- [Log de Terminal] –
Registra conclusão de [Processa
Preferências]
- Escreve: "Relatório Gerencial de
Preferências"
- Gera e imprime o relatório, a partir do [Registro de
Preferências]
- [Log de Terminal] –
Registra a emissão do Relatório Gerencial
|
13.
Transmissão de
dados
- Limpa a tela e escreve
"Transmitindo
dados..."
- [Log de Terminal] –
Registra início do evento [Transmissão de
dados]
- Chama a Rotina Externa [Conecta
Central]
- Estabelece conexão
(criptografada) com o computador
central
- Fecha os arquivos [Registro de Preferências] e [Log de Terminal]
- Chama a Rotina Externa [Transmite dados]
- Envia arquivos [Registro de Preferências] e [Log de Terminal]
(arquivo de exemplo:
61812145-02102022-Pref )
(arquivo de exemplo:
61812145-02102022-Log )
- Chama a Rotina Externa [Conecta
Central]
- Encerra a conexão
(criptografada) com o computador
central
- Reabre o arquivo [Log de
Terminal]
- [Log de Terminal] –
Registra conclusão da Transmissão de Dados
- Escreve "Transmissão de
dados concluída."
|
14.
Limpa a tela e escreve:
"Relatório Gerencial de Atividade do Terminal"
- Gera e imprime um
Relatório Gerencial
- A partir do arquivo [Log de
Terminal]
- [Log de Terminal] –
Registra a emissão do Relatório Gerencial
|
15.
Histórico de
dados
(Arquiva dados dos últimos
30 dias de operação do Terminal.)
- Move para o Histórico os
arquivos
- [Registro de Preferências] ( exemplo:
61812145-02102022-Pref )
- [Log de Terminal] ( exemplo:
61812145-02102022-Log )
- Exclui arquivos com mais de 30 dias de idade.
- [Log de Terminal] –
Registra a manutenção do Histórico de dados.
- [Log de Terminal] –
Registra entrada na fase de Desligamento.
|
16.
Desligamento
"Processamento encerrado. Desligando o
Terminal."
- Fecha
os arquivos [Registro
de Preferências] e [Log de Terminal]
- Grava um arquivo
Sinalizador de Desligamento Correto (SDC).
- Desliga o
Terminal.
|
4.3. Divagando sobre atividades
maliciosas no Aplicativo Fruticrático
Para
enfatizar a relevância de cada elemento e de cada fase (do desenvolvimento à
utilização) pertinentes ao chamado "ciclo de vida" de qualquer software,
analisemos o nosso Aplicativo Fruticrático, em busca de possibilidades de
atividades maliciosas.
4.3.1. Imaginando motivos para
atividades maliciosas
·
Suponhamos que a nossa Rede de Centrais de
Abastecimento compre frutas de um fornecedor que tenha interesse em melhorar o
"desempenho" de determinadas frutas em detrimento de outras, nas pesquisas
realizadas pelos Terminais Fruticráticos.
·
Suponhamos ainda que tal fornecedor esteja ciente
de que essa "melhora de desempenho" seria vista como aceitável em determinadas
regiões, porém vista com desconfiança em outras
regiões.
·
Suponhamos finalmente que esse fornecedor tenha
influência sobre desenvolvedores (internos ou externos) do nosso Sistema de
Terminais, de modo que tais "profissionais" incluíssem algum código malicioso no
Código-Fonte do Aplicativo ou em alguma das suas Rotinas
Externas.
4.3.2. Imaginando a concretização de
uma atividade maliciosa
Assumindo as más intenções das hipóteses acima,
imaginemos como um talentoso desenvolvedor poderia inserir em nosso Aplicativo
um código malicioso que atendesse aos anseios do fornecedor
desonesto.
Notemos
que o Código-Fonte chama estas Rotinas Externas:
·
[Teclado Numérico]
·
[Valida CPF]
·
[Musiquinha]
·
[Processa Preferências]
·
[Conecta Central]
·
[Transmite dados]
Observemos que:
§ A Rotina Externa
[Processa Preferências] é chamada no passo 12 do nosso
exemplo.
§ O passo 12 ocorre durante o Encerramento Diário de uso dos Terminais.
§ O passo 12 ocorre antes da Emissão dos Relatórios Gerenciais e da Transmissão de
Dados.
§ Assim sendo, torna-se
impossível usar tais Relatórios para "conferir" o arquivo [Registro de
Preferências].
Portanto, uma forma "bastante convidativa" para o
talentoso desenvolvedor adulterar os resultados do Aplicativo, seria programar a
Rotina Externa [Processa Preferências] para:
Consultar o [Log de
Terminal] e verificar se Terminal está sob
teste.
|
Terminal sob
teste
- Processar
normalmente o [Registro de Preferências] (totalizações
etc.)
|
Terminal sob uso
normal
- Consultar o ID do
Terminal
- Consultar uma
tabela de IDs versus localização dos
Terminais
- Determinar a
localização do Terminal
- Consultar uma
Tabela de alterações programadas, conforme a localização do
Terminal.
Por exemplo:
Região
|
Alteração no
[Registro de Preferências] |
N |
Agressiva |
NE |
Agressiva |
CO |
Nenhuma |
SE |
Branda |
S |
Moderada |
- Processar o
[Registro de Preferências], aplicando a alteração
programada.
|
"Devolver" ao
Programa Principal o arquivo [Registro de Preferências].
|
Considere-se ainda que, para alterar os resultados
globais das pesquisas em cada região, seria necessário que um percentual elevado
dos Terminais (preferivelmente todos) estivesse utilizando o Aplicativo contendo
código malicioso.
Isto
significa que, para lograr tal feito,
não bastaria ao fornecedor desonesto mobilizar, por exemplo, uma ação de
hackers que conseguissem invadir alguns Terminais para alterar o software em uns
poucos estabelecimentos.
4.3.3. Tentando constatar uma
atividade maliciosa
Suponhamos que, na Administração da Rede de
Centrais de Abastecimento (a contratante deste Sistema de Terminais
Fruticráticos), os Gestores, analisando os resultados das pesquisas, viessem a
suspeitar do "desempenho muito melhorado" de determinadas frutas, em
determinadas regiões geográficas.
Suponhamos ainda que, por quaisquer motivos, esses
Gestores tenham total controle sobre os computadores totalizadores das Centrais
Regionais e total confiança nos resultados recebidos dos mesmos, de modo que sua
desconfiança recaísse sobre os inocentes Terminais
Fruticráticos.
4.3.3.1. Constatando por meio de
testes práticos
Embora
esses Gestores não tivessem como saber, a priori, que os Terminais
Fruticráticos, assim como a sua Rotina Externa maliciosa [Processa
Preferências], operam de forma maliciosa sob condições normais de uso, porém de forma irrepreensível sob condições de teste,
é evidente que quaisquer bons especialistas em software os aconselhariam a
testar os Terminais procurando bloquear essa possível "dupla
personalidade".
Assim, a
forma prática de detectar uma adulteração dos resultados
seria:
·
Nas "regiões geográficas suspeitas", testar uma
quantidade representativa de Terminais sob condições
normais de uso, ou seja, sem utilizar o botão [Testar Terminal] e sem admitir qualquer interferência que permitisse aos
Terminais detectar que estariam sendo testados.
·
Durante estes testes, registrar as preferências dos
Clientes, utilizando algum tipo de recurso de aferição externo aos Terminais,
quer fosse imprimindo a tela a cada preferência confirmada, quer fosse filmando,
ou o que seja...
4.3.3.2. Constatando por análise de
software
Considerando que os mencionados Gestores não teriam
como saber, a priori, em qual camada (software, sistema operacional,
hardware...) dos Terminais poderia existir algum código malicioso, seria
necessário compor uma equipe de especialistas altamente qualificada, munida das
ferramentas (softwares) de análise que considerassem necessárias, e exigir dos
fornecedores dos softwares o acesso pleno e irrestrito aos Códigos-Fonte do
Aplicativo Fruticrático, de suas Rotinas Externas, do Sistema Operacional
Utilizado etc.
Como já
mencionado em 3.2.1 item A.2, dependendo da
extensão e da complexidade dos Códigos-Fonte, esta tarefa poderá se estender no
tempo, acarretar custos elevados, produzir resultados que certamente serão
questionados por "experts" (quase
sempre ineptos formuladores de opiniões de aluguel...)
4.3.3.3. Constatando por outras
análises
É
possível também aplicar métodos estatísticos aos resultados das pesquisas,
estabelecer correlações, comparações de resultados atuais e históricos, de
resultados regionais e globais, análise de resultados de diferentes Terminais na
mesma região etc.
Entretanto, estas análises post-mortem poderiam, quando muito,
caracterizar fortes indícios, mas não prova irrefutável da ocorrência de atividades
maliciosas.
5. Sistemas Computacionais
De
maneira abrangente e simplificada, um Sistema Computacional (genérico) consiste
de um conjunto de Aplicativos (softwares) inter-relacionados, o hardware
(equipamentos), o ambiente tecnológico em que esses softwares irão "rodar", bem como os recursos humanos
responsáveis pela sua implantação, operação e
manutenção.
6. Sistemas Computacionais de Missão Crítica
Já,
Sistemas de Missão Crítica são aqueles concebidos para prover serviços
computacionais essenciais a
instituições, entidades, órgãos públicos, negócios etc., primando por garantir
(aos dados, aos processos e aos resultados) as seguintes
características:
·
não-interrupção;
·
precisão;
·
qualidade;
·
segurança;
·
confiabilidade;
·
rastreabilidade (traceability).
Evidentemente, para garantir tais capacidades e
características, é necessário que a gestão de um Sistema de Missão Crítica tenha
total controle sobre todos os aspectos de desenvolvimento, implantação,
manutenção, utilização, segurança etc.:
·
do software utilizado em sua
operação;
·
do hardware utilizado em sua operação;
·
do ambiente tecnológico em que irá
operar;
·
de todos os recursos humanos envolvidos.
7. Requisitos Mínimos para Validação
de Confiabilidade de Sistemas Computacionais
Podemos
agora enunciar um conjunto básico de requisitos de confiabilidade para Sistemas
Computacionais em geral,
Homologação
Em
geral, homologação se refere à adequação dos softwares (Sistema) às necessidades
dos usuários e à sua compatibilidade em relação ao ambiente tecnológico em que o
Sistema operará.
Para não
entrarmos em aspectos como assinaturas digitais, criptografia etc., utilizaremos
o termo "homologação" para designar um conjunto de providências (exames
técnicos, testes, auditorias, due
diligences, ou o que seja...) garantidoras de que, uma vez examinados,
testados, aprovados e instalados, o software, o sistema operacional e o hardware
não mais serão modificados, durante todo o período de sua utilização.
R E Q U I S I T O
S
|
|
|
|
|
A - Camada do
Aplicativo |
|
- Que todos os Códigos-Fonte sejam submetidos
a um processo de homologação realizado durante o tempo que se faça
necessário, com o uso de ferramentas de análise estática e
dinâmica reconhecidas pela comunidade global de desenvolvedores de
software, como confiáveis, adequadas e eficientes para o tipo
de Código-Fonte e o volume de linhas de código a serem
analisadas.
|
|
- Que todos e quaisquer Elementos Externos (p.ex., Bibliotecas e APIs de
terceiros) sejam também homologados, pelos mesmos meios
utilizados na homologação
dos Códigos-Fontes do
Sistema.
|
|
- Que os Códigos-Fonte homologados, bem como os Elementos Externos homologados, sejam exatamente os mesmos
submetidos ao processo de Compilação para gerar os Programas Executáveis do
Sistema.
|
|
- Que os Compiladores e Linkers usados para gerar os Programas Executáveis sejam produtos amplamente utilizados
pela comunidade global de desenvolvedores de software, sem quaisquer alterações e que,
uma vez selecionados, sejam homologados.
|
|
- Que os Compiladores e Linkers usados para gerar os Programas Executáveis sejam exatamente os mesmos homologados.
|
|
- Que, durante os processos de Compilação, os Compiladores e Linkers incorporem aos Programas Executáveis somente os elementos homologados
(Códigos-Fonte e Elementos Externos), garantindo-se a não incorporação
de quaisquer elementos
não-homologados, quer presentes no ambiente de Compilação, quer trazidos de
ambientes externos (p.ex., via Internet).
|
|
- Para cumprimento do item
anterior, que todos os Scripts
de Compilação e Linkagem sejam também homologados, adotando-se medidas para
garantir que tais Scripts homologados, e somente eles, sejam
utilizados em Tempo de
Compilação.
|
|
- Que sempre se possa
aferir que os Programas
Executáveis carregados nos Dispositivos sejam exatamente os mesmos gerados
nos passos anteriores e devidamente homologados.
|
|
Se
desejar compreender esta camada em detalhe, volte ao tópico 3.2.1, itens A
e B.
Caso
contrário, prossiga para o próximo item. |
|
|
|
B - Camada do Sistema
Operacional
|
|
- Que o Sistema Operacional tenha todos
os seus componentes completa e detalhadamente homologados, incluindo-se interfaces do
usuário, serviços, drivers e
runtimes, kernel etc.
|
|
- Que o Sistema Operacional utilizado
seja exatamente aquele homologado.
|
|
Se
desejar compreender esta camada em detalhe, volte ao tópico
3.2.2.
Caso
contrário, prossiga para o próximo item. |
|
|
|
C - Camada do
Hardware
|
|
- Que os softwares
contidos em chips regraváveis (Firmware) sejam completa e detalhadamente homologados. (p.ex., BIOS, chips de
segurança, Real Time Clock
(RTC)
etc.)
|
|
- Que em cada unidade de Hardware
existam recursos de validação capazes de garantir que os Firmwares presentes
sejam exatamente aqueles que foram homologados.
|
|
- Que não existam
quaisquer recursos capazes
de regravar ou modificar
Firmware, em quaisquer partes do Código-Fonte, ou do Sistema Operacional, ou de
mídias externas eventualmente usadas no Sistema.
|
|
Se
desejar compreender esta camada em detalhe, volte ao tópico
3.2.3.
Caso
contrário, prossiga para o próximo item. |
|
|
|
E - Em relação aos
procedimentos externos ao Sistema
|
|
- Que o Sistema Operacional e os Programas Executáveis
carregados nos Dispositivos sejam exatamente os mesmos gerados a
partir dos Códigos-Fonte homologados.
|
|
Se
desejar compreender esta camada em detalhe, volte ao tópico 3.2.1, item
C. |
|
8.
Conclusões?
Em minha
modesta opinião, como procurei demonstrar ao longo deste artigo, para podermos
apenas supor a existência de um Sistema Computacional 99,999% seguro e confiável
(deixando 0,001% por conta dos bugs...), fazem-se necessários:
·
O contínuo atendimento a um extenso conjunto de
Requisitos Mínimos para Validação de Confiabilidade de Sistemas, pelos seus
gestores, desenvolvedores, operadores e stakeholders. E aqui, a expressão
"contínuo atendimento" significa que os mencionados Requisitos Mínimos devem ser
aplicados não apenas às versões iniciais de Software, Bibliotecas Externas,
Compiladores, Linkers, Sistemas Operacionais, Hardware, Firmware etc., mas
também a todos e quaisquer updates, upgrades, ou mínimas alterações que
venham a sofrer.
·
A excelência das práticas de gestão de
desenvolvimento, gestão de pessoal
técnico, gestão de recursos
internos e externos e elementos de segurança, conduzindo também à certeza de que
todos e quaisquer recursos utilizados no Sistema sejam exatamente aqueles
avaliados e aprovados segundo os mencionados Requisitos Mínimos para Validação
de Confiabilidade.
·
A sistemática "abertura" do Sistema para reexames
técnicos completos e plenos sob todos os aspectos.
E você, caro(a)
Leitor(a)?
Quais as suas
conclusões?
Copyright© 2022 -
2023
©Alfredo
Cyrino / Indigo Virgo®
- Por favor, não
reproduza este artigo, no todo ou em parte.
- Isto comprometeria o
design (formatação, indentação etc.) planejado para favorecer a
didática.
- Quaisquer partes do
texto perderão seu significado, se reproduzidas fora do contexto.
- Se desejar
compartilhar, apenas copie o link deste post.
- O autor lhe agradece
por haver lido o artigo e por respeitar este
pedido.