✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

quarta-feira, 8 de maio de 2019

🐶 Mumbly e o Mistério do Mainframe que Jurava Estar Seguro

Bellacosa Mainframe e o mistério do mainframe que jurava estar seguro

☕ Um Café no Bellacosa Mainframe

🐶 Mumbly e o Mistério do Mainframe que Jurava Estar Seguro

Firewalls, criptografia, autenticação, RACF, Zero Trust, ameaças, insiders, Red Team e aquele acesso das 03:17 que estava perfeitamente autorizado — mas não deveria estar acontecendo.

Há personagens que chegam a uma investigação arrombando portas, apontando armas e gritando ordens.

Mumbly não.

Ele aparece de sobretudo, dirige uma lata-velha, resmunga alguma coisa incompreensível e fica olhando para o suspeito com aquela expressão de quem já percebeu algo que ninguém mais percebeu.

E então vem aquela risadinha.

Heh-heh-heh-heh-heh...

Perfeito para investigar cybersecurity.

Porque segurança de computadores tem uma característica curiosa: quando ocorre um grande incidente, frequentemente descobrimos que várias partes do sistema estavam funcionando exatamente como foram configuradas para funcionar.

O firewall permitiu a conexão.

O certificado era válido.

A criptografia funcionou.

A senha estava correta.

O MFA foi aprovado.

O RACF autorizou.

O CICS executou.

O COBOL retornou RETURN-CODE = 0.

E alguém acabou de fazer algo que jamais deveria ter acontecido.

Mumbly ergueria uma sobrancelha.

Heh-heh-heh...

Temos um caso.

Antes de entrar na LPAR, vale apresentar nosso investigador. The Mumbly Cartoon Show foi produzido pela Hanna-Barbera e estreou nos Estados Unidos em 11 de setembro de 1976. Foram produzidos 16 episódios, com Mumbly dublado originalmente por Don Messick e Chief Schnooker por John Stephenson. O cão detetive de sobretudo trabalhava solucionando crimes enquanto seu chefe humano nem sempre demonstrava a mesma competência. (Wikipedia)

No Brasil, ficou conhecido como Rabugento, o Cão Detetive, com Pietro Mário na voz do protagonista e Guálter de França como Chefe Sinuca na dublagem registrada pela Herbert Richers. (DB - Dublagem Brasileira)

E existe uma conexão especialmente divertida: Mumbly é frequentemente descrito como uma paródia canina do detetive Columbo — sobretudo, comportamento aparentemente desajeitado, insistência e aquela capacidade de incomodar o suspeito até a verdade aparecer.

Exatamente o método que usaremos.

🕵️ CAPÍTULO 1 — O sistema estava seguro

Nosso caso começa numa grande empresa fictícia.

Chamaremos de:

BELLACOSA BANK

O diretor pergunta ao responsável pela infraestrutura:

— Nosso sistema está protegido?

Resposta:

— Claro!

E começa o inventário:

Firewall .............. ✔
WAF ................... ✔
TLS ................... ✔
AES ................... ✔
MFA ................... ✔
RACF .................. ✔
SIEM .................. ✔
Antivírus ............. ✔
Backups ............... ✔

Mumbly olha para a lista.

Hmmmmmm...

E resmunga.

Porque o primeiro erro de cybersecurity está diante dele:

ter controles de segurança não significa necessariamente estar seguro.

Essa diferença parece filosófica, mas é engenharia.

Um firewall resolve determinados problemas.

Criptografia resolve outros.

MFA resolve outros.

RACF resolve outros.

Nenhum deles consegue responder sozinho à pergunta:

“O sistema está fazendo somente aquilo que deveria fazer?”

É aí que começa nossa investigação.

🔥 CAPÍTULO 2 — O primeiro suspeito: Firewall

Durante muito tempo aprendemos segurança usando a metáfora do castelo:

             INTERNET
                 |
                 |
          +-------------+
          |  FIREWALL   |
          +-------------+
                 |
       =====================
       REDE CORPORATIVA
       =====================
           |          |
        SERVER      SERVER

Do lado de fora estão os bárbaros.

Dentro das muralhas estão os cidadãos confiáveis.

É uma metáfora útil.

Mas perigosa.

Porque cria uma conclusão implícita:

EXTERNO = NÃO CONFIÁVEL
INTERNO = CONFIÁVEL

Mumbly atravessa o firewall, olha para trás e resmunga:

Hmmmm...

O firewall nunca prometeu isso.

Ele controla comunicações segundo determinadas políticas.

Um packet filter poderia encontrar:

SOURCE      = 192.168.20.10
DESTINATION = 10.20.10.50
PROTOCOL    = TCP
PORT        = 443

e decidir:

ALLOW

Isso significa:

essa comunicação atende à política.

Não significa:

essa pessoa é honesta.

Nem:

essa operação é legítima.

Muito menos:

o que acontecer dentro dessa conexão será seguro.

🧱 CAPÍTULO 3 — Nem todo firewall é igual

O primeiro dos nossos infográficos apresentava diversos tipos de firewall.

A ideia geral está correta, mas precisamos separar tecnologias, arquiteturas e gerações.

Um packet-filtering firewall trabalha principalmente com características dos pacotes.

Um firewall stateful vai além.

Ele mantém contexto sobre conexões.

Simplificando:

SOURCE       PORT     DESTINATION    PORT     STATE

10.1.1.20    49152    10.2.1.30      443      ESTABLISHED
10.1.1.21    50233    10.2.1.31      22       ESTABLISHED

Agora o equipamento pode perguntar:

“Este pacote pertence a uma comunicação que já conheço?”

É uma enorme evolução sobre examinar pacotes isoladamente.

Mas ainda existe um problema.

Imagine:

HTTPS
TCP/443

Perfeitamente permitido.

Dentro dele:

POST /transfer

E dentro dessa requisição:

{
  "origem": "12345",
  "destino": "98765",
  "valor": 9800000
}

O firewall pode estar completamente satisfeito.

Mumbly não.

🌐 CAPÍTULO 4 — Então aparece o WAF

Agora acrescentamos outra camada:

INTERNET
   |
   v
FIREWALL
   |
   v
WAF
   |
   v
API GATEWAY
   |
   v
APPLICATION

O Web Application Firewall consegue observar aspectos específicos do tráfego HTTP/HTTPS e aplicar políticas relacionadas à aplicação.

Isso melhora enormemente nossa defesa.

Mas novamente:

WAF ALLOWED

não significa:

BUSINESS TRANSACTION IS LEGITIMATE

Essa diferença será fundamental quando chegarmos ao COBOL.

🔐 CAPÍTULO 5 — O segundo suspeito: criptografia

Mumbly encontra uma placa:

AES-256

O administrador sorri.

— Nossos dados são criptografados!

Mumbly responde:

Hmmmm...

Excelente.

Mas onde estão as chaves?

Silêncio.

Essa pergunta muda completamente a investigação.

Criptografia simétrica, como AES, utiliza segredo compartilhado para proteger dados.

Criptografia de chave pública trabalha com uma estrutura envolvendo chave pública e privada.

Na prática, sistemas modernos frequentemente combinam mecanismos.

Conceitualmente:

CRIPTOGRAFIA ASSIMÉTRICA
          |
          v
ESTABELECIMENTO DE CONFIANÇA/
SEGREDO DE SESSÃO
          |
          v
CRIPTOGRAFIA SIMÉTRICA
          |
          v
GRANDE VOLUME DE DADOS

Por quê?

Entre outros motivos, desempenho e características distintas dos algoritmos.

Mas nosso detetive não está interessado apenas no algoritmo.

Está procurando confiança.

🗝️ CAPÍTULO 6 — Quem guarda a chave da chave?

Imagine que CUSTOMER.DATA esteja perfeitamente criptografado.

Fantástico.

Agora alguém encontra no programa:

01  WS-CRYPTO-KEY PIC X(32)
    VALUE 'MINHA-SUPER-CHAVE-SECRETA'.

Mumbly começa a rir.

Heh-heh-heh-heh-heh...

A matemática continua funcionando.

A arquitetura de segurança, não.

O problema real passa a incluir:

Quem cria a chave?

Quem possui acesso?

Onde ela fica?

Pode ser exportada?

Como ocorre a rotação?

Quem consegue substituí-la?

Existe auditoria?

Existe separação de funções?

Existe hardware dedicado para protegê-la?

É aí que o mundo IBM Z fica fascinante.

Entram elementos como ICSF, hardware criptográfico, certificados, key rings e políticas de acesso.

Segurança criptográfica empresarial não é:

AES = ON

É um ecossistema.

🚚 CAPÍTULO 7 — Data at rest, data in transit e data in use

Mumbly encontra três salas.

Na primeira:

DATA AT REST

São datasets, bancos, arquivos, volumes e backups.

Na segunda:

DATA IN TRANSIT

São dados atravessando redes.

Na terceira:

DATA IN USE

Agora a coisa fica interessante.

Porque podemos possuir:

DISK
  ↓
ENCRYPTED DATA
  ↓
APPLICATION
  ↓
DECRYPT
  ↓
PROCESSING

Em algum momento uma aplicação autorizada precisa utilizar os dados.

Consequentemente:

criptografia não substitui controle de acesso.

E controle de acesso não substitui criptografia.

Essa é a essência de defense in depth.

🪪 CAPÍTULO 8 — Mumbly pergunta: “Quem é você?”

Chegamos à autenticação.

Temos senha.

PIN.

OTP.

Biometria.

Certificados.

Tokens.

Security keys.

Passwordless.

MFA.

Mas antes de decorar tecnologias precisamos aprender uma separação fundamental:

IDENTIFICATION
      ↓
Quem você afirma ser?

AUTHENTICATION
      ↓
Você consegue provar?

AUTHORIZATION
      ↓
O que você pode fazer?

Um usuário pode autenticar corretamente e continuar sem autoridade para determinado recurso.

Essa distinção é essencial no mainframe.

🏦 CAPÍTULO 9 — RACF entra na delegacia

Imagine:

USERID ABC123
PASSWORD ********

Autenticação concluída.

Mas ABC123 tenta acessar:

BANK.PROD.CUSTOMER.MASTER

Agora precisamos perguntar:

ABC123 possui READ?

Talvez sim.

Depois:

Possui UPDATE?

Talvez não.

ALTER?

Definitivamente esperamos que isso tenha sido pensado cuidadosamente.

Esse é o princípio de least privilege:

conceder somente os privilégios necessários para executar determinada função.

Um desenvolvedor COBOL iniciante precisa compreender isso muito cedo.

Seu programa não vive sozinho.

Ele executa dentro de uma arquitetura de identidade e autorização.

🧑‍💻 CAPÍTULO 10 — Então Mumbly encontra o COBOL

Aqui nossa investigação muda.

O sistema é:

Mobile App
    |
   TLS
    |
   WAF
    |
API Gateway
    |
z/OS Connect
    |
   CICS
    |
   RACF
    |
PGMPAY01
    |
   Db2

Uma requisição chegou.

Firewall:

OK

WAF:

OK

TLS:

OK

Identidade:

OK

RACF:

OK

CICS:

OK

E agora o programa recebe:

TRANSFER-AMOUNT = 9.800.000

Quem decide se aquela transferência faz sentido?

Talvez seja justamente o sistema de negócio.

💰 CAPÍTULO 11 — Uma linha COBOL também pode ser cybersecurity

Considere:

IF TRANSFER-AMOUNT > DAILY-LIMIT
    MOVE 'Y' TO ADDITIONAL-REVIEW
END-IF.

Isso parece uma regra bancária.

E é.

Mas também constitui controle de risco.

Podemos adicionar:

IF DESTINATION-COUNTRY NOT = CUSTOMER-USUAL-COUNTRY
   AND TRANSFER-AMOUNT > HIGH-RISK-LIMIT
       PERFORM REQUEST-ADDITIONAL-VALIDATION
END-IF.

Então descobrimos três níveis diferentes:

NETWORK AUTHORIZATION
        |
        | Posso estabelecer comunicação?
        v

SYSTEM AUTHORIZATION
        |
        | Posso acessar o recurso?
        v

BUSINESS AUTHORIZATION
        |
        | Posso executar ESTA operação?
        v

TRANSACTION

E é nesse terceiro nível que milhões de linhas COBOL sustentam controles críticos de negócio.

💣 CAPÍTULO 12 — Mumbly encontra um usuário perfeitamente legítimo

Às 03:17...

Sim, exatamente 03:17.

Um registro aparece:

USER ABC123
LOGIN SUCCESSFUL

Nada estranho.

Depois:

03:17:03 CUSTOMER READ
03:17:04 ACCOUNT READ
03:17:05 ACCOUNT READ
03:17:06 ACCOUNT READ
03:17:07 ACCOUNT READ

Alguns minutos depois:

38.421 RECORDS ACCESSED

RACF diz:

AUTHORIZED

Mumbly:

Hmmmmmmmmmm...

Normalmente ABC123 consulta 30 registros por dia.

Agora consultou 38 mil.

Essa é uma descoberta extraordinariamente importante:

acesso autorizado pode produzir comportamento malicioso.

👤 CAPÍTULO 13 — O insider não precisa derrubar a porta

O atacante externo pode precisar superar:

Firewall
WAF
MFA
RACF
Segmentation
Application Security

O insider talvez possua:

USERID válido
equipamento válido
VPN válida
acesso válido
conhecimento interno
autorizações legítimas

Seu caminho começa vários quilômetros depois da muralha.

Por isso:

AUTHENTICATED

não significa:

TRUSTED FOREVER

AUTHORIZED

não significa:

BEHAVIOR IS LEGITIMATE

Mumbly encontrou uma pista importante.

🎬 CAPÍTULO 14 — Uma fotografia não resolve o caso

Veja:

ABC123 READ CUSTOMER

Parece normal.

📸 Temos uma fotografia.

Agora:

03:17 Login incomum
03:18 Dataset sensível
03:19 Volume anormal
03:20 Nova aplicação
03:21 Consulta em massa
03:22 Transferência externa

Temos um filme.

🎬

Esse princípio ajuda a compreender SIEM, correlação, analytics e detecção comportamental.

Podemos coletar informações de várias fontes:

RACF ──────┐
SMF ───────┤
CICS ──────┤
Db2 ───────┤
MQ ────────┼──> CORRELATION
TCP/IP ────┤          |
WAF ───────┤          v
API ───────┤       ANALYTICS
Cloud ─────┘          |
                      v
                    ALERT

Uma ocorrência talvez não diga nada.

A sequência conta uma história.

Mumbly sempre soube disso.

Um detetive não resolve crimes olhando apenas para uma pegada.

Ele procura relações entre pistas.

🧮 CAPÍTULO 15 — Risk Scoring entra na investigação

Agora podemos transformar contexto em risco.

Não existe uma fórmula universal como esta, mas podemos imaginar pedagogicamente:

RISK SCORE =
    IDENTITY
  + DEVICE
  + NETWORK
  + BEHAVIOR
  + TRANSACTION
  + RESOURCE
  + THREAT CONTEXT

ABC123:

Known user ..................  0
Known workstation ...........  0
Unusual hour ................ 15
Sensitive resource .......... 20
Abnormal volume ............. 30
New destination ............. 20
Privilege anomaly ........... 30
                              ---
                              115

Em vez de simplesmente:

ALLOW
DENY

podemos pensar em respostas graduais:

ALLOW

ALLOW + MONITOR

STEP-UP AUTHENTICATION

LIMIT

REQUIRE APPROVAL

ISOLATE

DENY

OPEN INCIDENT

Isso representa uma evolução enorme da segurança binária.

🏰 CAPÍTULO 16 — Mumbly derruba o castelo

Finalmente chegamos ao Zero Trust.

O modelo antigo poderia implicitamente favorecer:

OUTSIDE
   ↓
UNTRUSTED

INSIDE
   ↓
TRUSTED

Zero Trust questiona essa confiança implícita.

Uma arquitetura mais madura pensa:

IDENTITY
    +
DEVICE
    +
RESOURCE
    +
CONTEXT
    +
POLICY
    +
RISK
    ↓
ACCESS DECISION

E mesmo depois de permitir:

CONTINUE OBSERVING

Esse último detalhe é fundamental.

Autorização não precisa representar um cheque em branco eterno.

🕸️ CAPÍTULO 17 — O Red Team pergunta algo diferente

Chegou a hora de Mumbly vestir o chapéu de Red Team.

Um teste superficial pergunta:

Como atravesso o firewall?

Um raciocínio muito mais interessante pergunta:

Onde esta organização deposita confiança?

Veja:

                    PRODUCTION
                  /      |      \
               CICS     DB2      MQ
                |        |        |
              COBOL     DBA    SERVICE
                |        |        |
               DEV     ADMIN    VENDOR
                 \       |       /
                    IDENTITY
                       |
                    HELPDESK

Isso é um grafo de confiança.

Agora existe uma pergunta deliciosamente Mumbly:

Qual caminho até produção possui menos resistência?

Talvez atacar:

Internet
→ Firewall
→ WAF
→ API
→ z/OS

seja difícil.

Mas existe:

Usuário
→ Helpdesk
→ Reset
→ Credencial
→ VPN
→ Ambiente interno

Ou:

Fornecedor
→ Service Account
→ Integração
→ MQ
→ Aplicação

Ou ainda:

Developer
→ Repository
→ Pipeline
→ Build
→ Load Library
→ Production

O Red Team não precisa necessariamente destruir a muralha.

Ele procura uma porta que alguém já deixou aberta.

📦 CAPÍTULO 18 — O assassino pode estar no pipeline

Mumbly encontra:

PGMPAY01.cbl

O fonte está perfeito.

Code review:

PASS

Testes:

PASS

Análise:

PASS

Mas existe uma cadeia:

SOURCE
  ↓
COPYBOOK
  ↓
REPOSITORY
  ↓
BUILD
  ↓
COMPILER
  ↓
LINK
  ↓
LOADLIB
  ↓
DEPLOY
  ↓
PRODUCTION

Comprometa uma etapa da cadeia e talvez você não precise alterar diretamente o fonte analisado.

Esse é o motivo pelo qual supply-chain security se tornou tão importante.

A pergunta deixa de ser:

O código está correto?

e vira:

Conseguimos provar que aquilo executando em produção corresponde ao artefato que acreditamos ter construído?

Essa é outra investigação inteira.

👻 CAPÍTULO 19 — O suspeito que ninguém interrogou: Service Account

Mumbly consulta a lista de usuários.

Humanos:

VAGNER01
MARIA02
JOAO03

E depois:

SVCMQ001
SVCBATCH
SVCAPI
CICSPROD

Hmmmmm...

Máquinas também possuem identidades.

Aplicações precisam conversar:

CICS
 ↓
MQ
 ↓
SERVICE
 ↓
API
 ↓
DATABASE

Um service account criado dez anos atrás pode ter acumulado privilégios porque, a cada problema, alguém decidiu:

“Libera mais um acesso para o batch funcionar.”

Depois de quinze anos:

SVCBATCH
    |
    +-- CUSTOMER.*
    +-- ACCOUNT.*
    +-- PAYMENT.*
    +-- CLAIMS.*
    +-- REPORT.*
    +-- ADMIN.*

Ele virou um fantasma com as chaves do prédio inteiro.

Essa é security debt.

🧑‍🔧 CAPÍTULO 20 — E o erro humano?

Um dos infográficos inclui corretamente erro humano entre ameaças.

Isso merece atenção.

Nem todo incidente nasce de:

EVIL HACKER

Pode nascer de:

PERMIT *

quando deveria ser:

PERMIT RESOURCE.X

Pode ser um certificado expirado.

Uma ACL errada.

Uma configuração esquecida.

Um dataset copiado para homologação contendo dados reais.

Um log com informação sensível.

Um backup sem a proteção esperada.

Um usuário que recebeu privilégio temporário e nunca o perdeu.

Ou simplesmente:

“Deixa assim porque está funcionando.”

Mumbly odeia essa frase.

Heh-heh-heh-heh...

🎩 CAPÍTULO 21 — White Hat, Black Hat e a confusão dos chapéus

O último infográfico tenta classificar hackers.

Serve como introdução, mas é perigoso transformar todos os “chapéus” em taxonomia rígida.

É melhor classificar atores em dimensões.

Autorização

AUTHORIZED
UNAUTHORIZED

Motivação

Financial
Espionage
Ideological
Revenge
Curiosity
Sabotage

Relação

External
Internal
Partner
Supplier

Capacidade

Low
Medium
High
Advanced

Recursos

Individual
Criminal organization
Corporate
State-supported

Assim conseguimos construir modelos de ameaça muito melhores.

Um adolescente usando ferramentas prontas e uma equipe altamente financiada podem explorar a mesma vulnerabilidade.

Mas representam riscos completamente diferentes.

🛡️ CAPÍTULO 22 — Prevent não basta

Mumbly olha novamente nossa arquitetura.

Encontramos:

Firewall
MFA
RACF
TLS
Encryption
WAF

Tudo isso é importantíssimo.

Mas segurança precisa pensar em todo o ciclo:

Essa visão é muito próxima da estrutura do NIST Cybersecurity Framework 2.0, que organiza os resultados de cybersecurity nas funções Govern, Identify, Protect, Detect, Respond e Recover. (Wikipedia)

O ponto pedagógico permanece: prevenção é somente parte do trabalho.

🚨 CAPÍTULO 23 — Assume Breach

Existe uma pergunta desconfortável que Mumbly faria:

E se o atacante já estiver dentro?

Essa pergunta muda completamente o projeto.

Em vez de:

COMO IMPEDIMOS A ENTRADA?

também perguntamos:

COMO LIMITAMOS O MOVIMENTO?

COMO DETECTAMOS?

COMO CONTEMOS?

COMO PRESERVAMOS EVIDÊNCIAS?

COMO RECUPERAMOS?

COMO SABEMOS O QUE FOI AFETADO?

A arquitetura precisa sobreviver à falha de um controle.

Essa é uma maneira poderosa de compreender defense in depth.

🔬 CAPÍTULO 24 — O programador COBOL também faz parte da defesa

Essa talvez seja a descoberta mais importante deste artigo.

O programador iniciante frequentemente imagina:

SEGURANÇA
   =
EQUIPE DE SEGURANÇA

Não.

Quem escreve:

IF USER-ROLE = 'ADMIN'

está implementando uma decisão de segurança.

Quem escreve:

DISPLAY CUSTOMER-CARD-NUMBER

pode estar criando exposição de dados.

Quem decide registrar:

PASSWORD=XXXXXXXX

em log está tomando uma decisão de segurança.

Quem cria:

IF AMOUNT > LIMIT
   PERFORM VALIDATE
END-IF

pode estar implementando controle antifraude.

Quem ignora:

RETURN-CODE

pode transformar uma falha de segurança em comportamento inesperado.

Cybersecurity não começa no firewall.

Nem termina no RACF.

Ela atravessa o software.

🧠 CAPÍTULO 25 — Mumbly finalmente monta o quadro

Na parede da delegacia temos todas as pistas:

                   CYBERSECURITY
                         |
         +---------------+---------------+
         |               |               |
       PEOPLE          PROCESS        TECHNOLOGY
         |               |               |
         +---------------+---------------+
                         |
                       ASSET
                         |
                      THREATS
                         |
                  ATTACK SURFACE
                         |
                      CONTROLS
                         |
         +---------------+---------------+
         |               |               |
      PREVENT          DETECT          RESPOND
         |               |               |
      Firewall          SMF             SOC
      RACF              Logs            IR
      MFA               SIEM            Isolate
      TLS               UEBA            Recover
      Crypto            Alerts          Forensics
         \               |               /
          +--------------+--------------+
                         |
                      EVIDENCE
                         |
                       RISK
                         |
                    GOVERNANCE

E no centro disso tudo:

                     BUSINESS
                        |
                        v
                      COBOL
                        |
             +----------+----------+
             |          |          |
            CICS       Db2         MQ
             \          |          /
              +---------+---------+
                        |
                       z/OS
                        |
                       IBM Z

Agora finalmente enxergamos o sistema inteiro.

🐶 CAPÍTULO 26 — Mumbly resolve o caso

Chefe Sinuca entra correndo.

— Mumbly! Descobri! O firewall estava funcionando!

Mumbly:

Hmmmm.

— O MFA também!

Hmmmm.

— O certificado era válido!

Hmmmm.

— RACF autorizou!

Hmmmm.

— O programa COBOL terminou com CC 0000!

Mumbly sorri.

Heh-heh-heh-heh-heh...

Porque essa era justamente a pista.

Nada havia “quebrado”.

O usuário possuía uma identidade legítima.

A comunicação era permitida.

O canal estava criptografado.

O recurso estava autorizado.

A transação tecnicamente funcionou.

Mas às 03:17, aquela identidade começou a executar uma sequência de operações incompatível com seu comportamento normal, em volume incomum, sobre recursos sensíveis.

O sistema tradicional perguntava:

WHO ARE YOU?

Depois evoluiu para:

WHO ARE YOU?
ARE YOU AUTHORIZED?

A segurança moderna precisa continuar:

WHO ARE YOU?

WHAT DEVICE?

FROM WHERE?

WHAT RESOURCE?

WHAT OPERATION?

WHEN?

HOW MUCH?

HOW OFTEN?

IS THIS NORMAL?

WHAT CHANGED?

WHAT IS THE CURRENT RISK?

SHOULD WE CONTINUE TRUSTING THIS SESSION?

Mumbly não encontrou uma porta arrombada.

Encontrou algo muito mais interessante:

uma cadeia de confiança que continuou confiando quando já deveria ter começado a desconfiar.

☕ EPÍLOGO — O firewall não era o culpado

É tentador terminar uma aula de cybersecurity dizendo:

“Precisamos de firewalls melhores.”

Mas Mumbly provavelmente resmungaria.

O firewall fez seu trabalho.

O RACF fez seu trabalho.

A criptografia fez seu trabalho.

O CICS fez seu trabalho.

O COBOL fez exatamente aquilo que alguém havia programado.

Esse é precisamente o problema.

Segurança madura não pode ser reduzida à existência de ferramentas.

Precisamos perguntar continuamente:

QUEM
   ↓
FAZ O QUÊ
   ↓
SOBRE QUAL RECURSO
   ↓
EM QUAL CONTEXTO
   ↓
COM QUAL PRIVILÉGIO
   ↓
PRODUZINDO QUAL COMPORTAMENTO
   ↓
GERANDO QUAL RISCO

Por isso aqueles cinco infográficos aparentemente simples — Firewall, Criptografia, Autenticação, Ameaças e Hackers — acabam nos levando a uma discussão muito maior sobre IAM, RACF, least privilege, defesa em profundidade, Zero Trust, SIEM, UEBA, Risk Scoring, supply chain, insider threat, Red Team, observabilidade, resposta a incidentes e segurança de aplicações COBOL.

E talvez exista uma lição ainda mais bonita para quem está começando no mainframe.

Não olhe para um programa COBOL simplesmente como:

INPUT
  ↓
PROCESS
  ↓
OUTPUT

Olhe assim:

IDENTITY
    ↓
AUTHORIZATION
    ↓
INPUT
    ↓
BUSINESS RULES
    ↓
RISK CONTROLS
    ↓
TRANSACTION
    ↓
DATA
    ↓
AUDIT TRAIL

Porque aquele velho programa de quarenta anos pode não ser apenas um sistema que calcula juros, liquida pagamentos ou atualiza uma conta.

Ele pode ser uma das últimas linhas de defesa do negócio.

E quando alguém disser:

“Mas o usuário estava autenticado...”

talvez seja hora de vestir o sobretudo, olhar novamente os SMF records, correlacionar CICS, Db2, RACF, MQ e logs da aplicação e perguntar:

“Autenticado, sim. Mas deveria estar fazendo isso?”

Do fundo do Data Center ouvimos:

Heh-heh-heh-heh-heh...

Mumbly encontrou outra pista. 🐶🔎

terça-feira, 7 de maio de 2019

🌭 O Dogão da Baixa Augusta – O Cão Noturno que Alimentou uma Geração Perdida

🌭 O Dogão da Baixa Augusta – O Cão Noturno que Alimentou uma Geração Perdida
por El Jefe – Bellacosa Mainframe Midnight Lunch Edition

Há coisas que só quem viveu entende.
E o Dogão da Baixa Augusta, meus caros padawans da madrugada, é uma dessas instituições invisíveis que sustentaram corpos cansados, corações partidos e sistemas operacionais humanos à beira do crash.

🌃 Origem – a Aurora do Dogão Subterrâneo
Voltemos aos anos 1990 e 2000, quando a Rua Augusta ainda era um portal de transição entre o glamour decadente da Paulista e o caos libertário do centro velho.
A noite fervia: punks, clubbers, drag queens, jornalistas alternativos, estudantes e os sobreviventes da Vila Buarque misturavam-se sob néons cansados e muros pichados.
Entre um after e um amor fugaz, lá estava ele — o Dogão, reluzente no vapor do carrinho, um farol de carboidrato na neblina da boemia paulistana.

🌭 A Arquitetura do Dogão Paulista
O dogão não era um simples cachorro-quente. Era uma entidade gastronômica.
Pão macio, salsicha dupla, vinagrete, milho, ervilha, purê de batata, batata palha, maionese e ketchup em cascata.
Cada ingrediente era uma camada da noite paulistana — um stack de sabores, tão caótico quanto o sistema da CPTM às 6 da manhã.
E o purê? Ah, o purê! Era o middleware que unificava tudo. Sem ele, o dogão seria apenas um log de dados corrompido.

🎭 As Lendas da Augusta
Dizem que o primeiro dogueiro lendário foi um ex-técnico de som que montava o carrinho depois de desmontar caixas de um show no Inferno Club.
Outros juram que o Dogão nasceu no front das portas do Clube Outs, quando um grupo de roqueiros famintos improvisou um lanche com tudo que tinha — e descobriu, acidentalmente, o equilíbrio perfeito entre desespero e delícia.
Há quem diga que o dogão salvou mais de mil romances e impediu outras tantas brigas. Era o “checkpoint” da noite — antes de voltar pra casa, antes de enfrentar o silêncio do amanhecer.

🌀 Adaptações e mutações
Com o tempo, o Dogão evoluiu — virou Dog Vegano, Dog Premium, Dog da Augusta Experience (sim, isso existe).
Mas o verdadeiro conhecedor sabe: dog bom é o da calçada, servido num guardanapo que não aguenta o molho.
Nada de pão artesanal ou maionese trufada — o dogão legítimo carrega o DNA da gambiarra, da sobrevivência urbana e do improviso genial.

💬 Fofoquices do Cinturão Noturno
Reza a lenda que DJs faziam fila ao lado de drag queens e grafiteiros, todos de olho no mesmo dogão.
Teve até banda indie que, no auge da fama, largou a coletiva de imprensa pra ir comer um “dogão raiz” antes de subir no palco da Augusta 473.
E dizem que um crítico gastronômico francês, de passagem pela cidade, descreveu o Dogão como “um atentado delicioso à ordem culinária”.
Ele não estava errado.

💡 Dicas do Bellacosa
Se for fazer o pilgrimage noturno:

Vá entre 1h e 4h da manhã, quando a Augusta mostra sua verdadeira face.
Peça o dogão completo, sem frescura.
E se o dogueiro te perguntar “purê, patrão?”, nunca diga não.
É como recusar JES2 num job de produção — simplesmente não se faz.

🖤 Reflexão do El Jefe Midnight Lunch
O Dogão é mais do que comida. É símbolo de resistência cultural, um mainframe ambulante de memórias urbanas.
Ele alimentou a contracultura paulistana, a juventude sem grana, o rock alternativo, os amores líquidos e as madrugadas eternas.

Hoje, a Baixa Augusta mudou, ganhou coworkings e bares gourmet. Mas ainda há carrinhos discretos guardando a chama original — o Dogão da Rua, que não precisa de login, QR Code ou status social pra te aceitar.

🌭 Bellacosa Mainframe – preservando os sabores do submundo paulistano desde o tempo do Diskman.

segunda-feira, 6 de maio de 2019

Rotunda da CIA Mogiana em Campinas - Memoria Ferroviária Paulista

Rotunda ferroviária da Mogiana : Complexo FEPASA em Campinas

Tema de outros vídeos em nosso canal, a Estação Central de Campinas, outrora abrigou um complexo centro ferroviário, coração da Cia Paulista e da Cia Mogiana.

Em suas instalações milhares de trabalhadores circulavam e trabalhavam nas mais diversas atividades, 24 horas por dia, 7 dias por semana.

Neste complexo havia duas rotundas, uma usina termoelétrica, central de telégrafo, marcenaria, carpintaria, mecânica leve, mecânica pesada, fundição, cozinha, cantina, oficina de costura, fabricação de vagões e carruagens e muito mais.

Após inúmeras tentativas, enfim consegui adentrar na EMDEC e com autorização visitei as ruínas da antiga rotunda, é impressionante o tamanho, contei 22 eslotes para locomotiva, me emocionei pensando em quantas locomotivas a vapor, diesel, elétrica estiveram armazenadas aqui.

Quanta riqueza e progresso trouxe estas instalações que ligava o interior ao litoral, trazendo e levando pessoas e bens, espero que um dia se concretize e se transforme num belo museu para as futuras gerações conhecerem um pouco mais da história.

Se gostou deixe seu like, e caso não seja inscrito no canal se inscreva. Muito obrigado pela visita.

Tag

#Campinas #Ferrovia #MemoriaFerroviaria #CiaPaulista #CiaMogiana #Trem #Locomotiva #Rotunda #RotundaFerroviaria #Vapor #Trilhos #Carris #Arquitetura #Arqueologia #Industrial #EstaçãoCultural #Estacao #Central

domingo, 5 de maio de 2019

IBM Mainframe Discovery : Capítulo XVII — A Última Fronteira Nunca Foi o Espaço

Bellacosa Mainframe apresenta o ibm mainframe parte xvii

☕ Um Café no Bellacosa Mainframe

Capítulo XVII — A Última Fronteira Nunca Foi o Espaço

IBM z17, Inteligência Artificial e o Futuro: A Nave Que Descobriu Que o Amanhã Sempre Chega

DÉCIMA QUARTA REGRA DOS VIAJANTES DO TEMPO

Nunca pergunte se uma tecnologia é velha.

Pergunte:

"Ela ainda aprende?"

Porque idade...

é apenas uma medida de tempo.

Aprender...

é uma medida de evolução.

Existe uma enorme diferença.

Finalmente Chegamos ao Fim...

...ou talvez não.

Depois de atravessar:

a arquitetura,

o Supervisor,

o JES,

o CICS,

o Db2,

o MQ,

o USS,

a Virtualização,

o Parallel Sysplex,

o DevOps...

chegamos à Ponte de Comando.

O lugar onde todos os caminhos se encontram.

Onde o passado conversa com o futuro.

Onde a próxima missão ainda está sendo escrita.

A Nave Continua Viajando

Imagine visitar um museu.

Você espera encontrar:

poeira.

placas antigas.

equipamentos desligados.

Mas ao abrir uma porta...

descobre que tudo continua funcionando.

Os motores permanecem ligados.

Os computadores continuam evoluindo.

Novas alas foram construídas.

Novas tecnologias chegaram.

A nave nunca virou museu.

Ela permaneceu em missão.

O Grande Erro da Galáxia

Existe uma previsão que se repete há mais de quarenta anos.

"O Mainframe vai desaparecer."

Curiosamente...

ela desaparece com muito mais frequência do que o próprio Mainframe.

É uma curiosidade quase cósmica.

Enquanto especialistas anunciam seu fim...

os bancos continuam funcionando.

As bolsas continuam negociando.

Os cartões continuam autorizando compras.

Os aviões continuam decolando.

Os hospitais continuam atendendo.

Talvez...

a realidade seja mais teimosa que as previsões.

Conheça o z15

Imagine uma nova nave entrando na Frota.

Ela não substitui as anteriores.

Ela carrega toda a experiência acumulada por gerações.

Mas recebe:

novos sensores.

novos motores.

novos computadores.

novas inteligências.

Essa nave chama-se:

IBM z15.

Ela representa mais um capítulo de uma história iniciada em 1964.

Uma história que poucos imaginavam ainda estar sendo escrita.

O Computador Que Aprende

Durante décadas os computadores apenas obedeciam.

Recebiam comandos.

Executavam.

Terminavam.

Agora imagine um navegador capaz de observar o universo.

Aprender padrões.

Encontrar anomalias.

Sugerir caminhos.

Auxiliar decisões.

É exatamente isso que a Inteligência Artificial trouxe ao IBM Z.

O Conselheiro Científico

Toda grande nave possui um cientista.

Não um cientista qualquer.

Um especialista capaz de analisar milhões de informações simultaneamente.

No universo IBM encontramos um novo tripulante.

watsonx.

Ele não pilota a nave.

Não substitui o comandante.

Mas ajuda toda a tripulação a compreender melhor o universo.

O Diário Vivo da Federação

Imagine que todos os acontecimentos da nave sejam registrados.

Temperatura.

CPU.

Discos.

Mensagens.

Logs.

Eventos.

Transações.

Agora imagine um sistema capaz de analisar tudo isso em tempo real.

Detectando:

anomalias.

riscos.

tendências.

Antes mesmo que um problema aconteça.

A observabilidade moderna tornou isso possível.

A IA Não Substitui o Engenheiro

Existe um medo recorrente.

"Os computadores vão substituir os programadores."

Talvez essa pergunta esteja errada.

Uma pergunta melhor seria:

"Quais programadores aprenderão a trabalhar junto com a IA?"

Durante toda a história da tecnologia...

as ferramentas mudaram.

Os bons engenheiros também.

O Laboratório da Nave

Imagine um enorme laboratório.

Ali trabalham:

COBOL.

Java.

Python.

Rust.

C++.

Go.

Node.js.

Todos utilizando:

IA.

APIs.

Git.

OpenShift.

Cloud.

Containers.

Nenhuma dessas tecnologias expulsou a outra.

Elas simplesmente aprenderam a cooperar.

O Enigma da Computação Quântica

Agora imagine uma porta ainda fechada.

Atrás dela existe um laboratório.

Ali trabalham computadores muito diferentes.

Eles não pensam apenas em:

zero.

um.

Exploram princípios completamente novos.

Estamos falando da:

Computação Quântica.

Ela ainda não substituirá o IBM Z.

Mas poderá tornar-se uma poderosa parceira em problemas específicos, como otimização, química molecular e criptografia.

Um Novo Tipo de Escudo

Imagine que alguém constrói uma arma capaz de atravessar todos os escudos conhecidos.

O que fazer?

Construir novos escudos.

É exatamente isso que acontece com a:

Criptografia Pós-Quântica.

O IBM Z já incorpora mecanismos preparados para enfrentar um futuro onde computadores quânticos possam ameaçar algoritmos criptográficos atuais.

Não é ficção.

É planejamento.

A Nuvem Também Mora Aqui

Existe outro mito.

"Cloud substitui Mainframe."

Na realidade...

é comum encontrarmos arquiteturas onde ambos trabalham juntos.

Imagine uma gigantesca federação.

Cada planeta possui suas especialidades.

Cloud oferece elasticidade.

Mainframe oferece processamento transacional massivo.

Linux fornece flexibilidade.

IA fornece inteligência.

Nenhum precisa eliminar o outro.

A Nave Aprendeu Novos Idiomas

Durante esta jornada conhecemos:

REST.

MQ.

JSON.

OpenAPI.

Python.

Git.

Docker.

Kubernetes.

OpenShift.

Ansible.

VS Code.

Agora surge outro detalhe curioso.

A nave continua falando COBOL.

E continuará falando por muito tempo.

Porque conhecimento acumulado possui enorme valor.

O Universo Está Ficando Mais Complexo

Há cinquenta anos...

um programa conversava com outro.

Hoje...

uma única transação pode atravessar:

API Gateway.

Load Balancer.

Cloud.

MQ.

Kafka.

OpenShift.

z/OS Connect.

CICS.

COBOL.

Db2.

E retornar em poucos milissegundos.

A tecnologia ficou mais complexa.

Mas também mais fascinante.

O Que Diria Wilhelm G. Spruth?

Se Wilhelm G. Spruth pudesse caminhar hoje pelos corredores de um moderno Data Center IBM Z...

provavelmente sorriria.

Em 2010 ele descreveu características únicas da plataforma:

alta disponibilidade.

virtualização.

segurança.

WLM.

Parallel Sysplex.

integração.

Esses pilares permanecem.

O que mudou foi o universo construído sobre eles.

APIs.

IA.

Containers.

Open Source.

DevOps.

Cloud.

Nada disso destruiu os fundamentos.

Apenas ampliou suas possibilidades.

A Pergunta Que Acompanhou Todo Este Livro

Chegamos finalmente à pergunta iniciada no Capítulo 1.

O Mainframe sobreviveu ao futuro?

Ou...

foi o futuro que acabou ficando parecido com o Mainframe?

Pense por um instante.

Hoje todos falam sobre:

alta disponibilidade.

virtualização.

containers.

automação.

segurança.

orquestração.

resiliência.

observabilidade.

criptografia.

governança.

escalabilidade.

Curiosamente...

essas ideias fazem parte da cultura IBM Z há décadas.

Talvez o Mainframe nunca tenha corrido atrás do futuro.

Talvez...

o futuro tenha demorado para alcançá-lo.

A Última Descoberta do Padawan

Durante esta viagem você talvez tenha percebido algo curioso.

Este livro nunca foi apenas sobre computadores.

Foi sobre pessoas.

Engenheiros.

Operadores.

Arquitetos.

Analistas.

Programadores COBOL.

Cada geração recebeu uma nave.

Nenhuma a construiu sozinha.

Cada uma acrescentou:

uma peça.

uma melhoria.

uma ideia.

Depois entregou a próxima geração.

Esse talvez seja o maior legado da engenharia.

Construir algo que sobreviva ao próprio construtor.

A Biblioteca Nunca Fecha

Lembra do primeiro capítulo?

Dissemos que não entrássemos em pânico.

Agora podemos acrescentar outra recomendação.

Nunca pare de aprender.

Porque existe uma regra curiosa no universo.

Quanto mais você aprende...

maior ele parece ficar.

A Última Página... Ou Apenas o Primeiro Capítulo?

Imagine fechar este livro.

Você acredita que terminou.

Mas então percebe algo.

Sua mesa possui:

um terminal 3270.

um notebook.

VS Code.

Git.

Python.

COBOL.

Ansible.

OpenShift.

IA.

Todos esperando.

O verdadeiro livro começa agora.

Porque conhecimento que não é praticado...

permanece apenas como tinta sobre papel.

A Mensagem Escondida em Toda a Jornada

Talvez você esperasse encontrar um livro sobre Mainframe.

Mas, no fundo...

ele sempre foi um livro sobre curiosidade.

Sobre nunca aceitar respostas fáceis.

Sobre desmontar mitos.

Sobre olhar para tecnologias antigas sem preconceito.

E olhar para tecnologias novas sem deslumbramento.

As maiores descobertas da humanidade quase sempre nasceram quando alguém fez uma pergunta simples.

"E se estivermos olhando para isso do jeito errado?"

Curiosidades do Diário de Bordo

🚀 O IBM Z continua evoluindo geração após geração, incorporando Inteligência Artificial, aceleração criptográfica, computação híbrida e integração com ecossistemas abertos.

🌍 Grande parte das transações financeiras mundiais continua dependendo diariamente das características de disponibilidade, segurança e escalabilidade desenvolvidas ao longo de décadas na plataforma.

🤖 Ferramentas de IA já auxiliam programadores COBOL na documentação, modernização, testes e análise de código, tornando o desenvolvimento mais produtivo.

🌌 A história do Mainframe demonstra que tecnologias verdadeiramente importantes raramente desaparecem; elas evoluem, adaptam-se e encontram novos papéis.

Diário Final de Bordo do Padawan COBOL

Se chegou até aqui...

você já não é exatamente um Padawan.

Ainda existe muito a aprender.

Sempre existirá.

Mas agora você conhece algo que muitos profissionais jamais descobriram.

Você percebeu que o IBM Z não é apenas um computador.

É uma filosofia de engenharia.

Uma coleção de ideias.

Uma tradição de confiabilidade.

Uma escola de arquitetura.

Uma prova de que boas decisões técnicas podem atravessar gerações.

A Última Regra do Guia do Mochileiro Mainframe

Antes de partir para sua próxima missão, grave uma última coordenada no seu Holocron Técnico:

Leve sempre uma toalha... e um bom manual de JCL.

A toalha ajuda quando a viagem fica turbulenta.

O JCL ajuda quando o ABEND chega sem avisar.

E, se ambos falharem...

faça o que todo grande explorador faz.

Sirva uma boa xícara de café.

Abra o SDSF.

Leia os logs com calma.

Converse com seus colegas de tripulação.

E continue explorando.

Porque, no universo do IBM Z, a maior aventura nunca foi executar um programa.

Sempre foi compreender a extraordinária engenharia construída por milhares de pessoas ao longo de mais de seis décadas.

Epílogo — Fim da Missão... Início da Próxima

A nave segue seu curso.

As estrelas continuam lá.

Novas tecnologias surgirão.

Outras desaparecerão.

Mas enquanto houver sistemas que precisem ser seguros, confiáveis, escaláveis e disponíveis, sempre haverá espaço para os princípios que você encontrou nesta jornada.

E talvez, algum dia, um novo Padawan pergunte:

"O Mainframe ainda existe?"

Você poderá sorrir, apontar para a imensidão da galáxia tecnológica e responder:

"Ele nunca deixou de existir. Você apenas não tinha percebido que ele sempre esteve pilotando a nave."

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.