✨ 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

Mostrar mensagens com a etiqueta Segurança Mainframe. Mostrar todas as mensagens

terça-feira, 21 de abril de 2026

🔥 Quem Realmente Manda no Seu z/OS? — RACF vs TSS vs ACF2, a Guerra Silenciosa que Decide Tudo

Bellacosa Mainframe fala sobre segurança mainframe RACF TSS ACF2

🔥 Quem Realmente Manda no Seu z/OS? — RACF vs TSS vs ACF2, a Guerra Silenciosa que Decide Tudo

Se você trabalha com mainframe há tempo suficiente, já sabe:
o sistema pode ser o mais estável do mundo… mas quem decide o que acontece nele não é o z/OS — é o ESM.

E aí entra o trio que moldou décadas de segurança no mainframe:

IBM RACF
CA Top Secret (TSS)
CA ACF2

Três filosofias. Três formas de pensar segurança.
E, mais importante: três maneiras completamente diferentes de cometer erros — ou evitá-los.

🧠 Capítulo 1 — Origem: Quando Segurança Virou Necessidade (não luxo)

Volta para os anos 70/80.

Mainframe já processava:

bancos
governo
folha de pagamento
defesa

E aí veio a pergunta que mudou tudo:

“Quem pode acessar o quê?”

A resposta não era trivial — porque o z/OS (na época MVS) não nasceu com segurança robusta nativa.

🔵 RACF (IBM)

Criado pela própria IBM:

integração total com o sistema
modelo corporativo
foco em governança

👉 DNA:

segurança como parte da arquitetura

🟢 TSS (CA Top Secret)

Criado pela CA:

foco em simplicidade
modelo centrado no usuário

👉 DNA:

segurança como controle direto

🟣 ACF2

Também da CA:

abordagem radicalmente diferente
rule-based

👉 DNA:

segurança como linguagem

🧬 Capítulo 2 — O DNA de Cada Um

🔵 RACF — O Burocrata Organizado

RACF pensa assim:


Usuário → Grupo → Recurso → Permissão

Ele cria estrutura.

Exemplo real:


ADDUSER DEV01 DFLTGRP(DEV)
PERMIT PROD.APP.* CLASS(DATASET) ID(DEV01) ACCESS(READ)

👉 RACF gosta de:

hierarquia
governança
previsibilidade

🟢 TSS — O Operador Pragmático

TSS elimina intermediários:


ACID → Permissões

Exemplo:


TSS PERMIT(DEV01) DATASET(PROD.APP.*) ACCESS(READ)

👉 TSS gosta de:

simplicidade
rapidez
controle direto

🟣 ACF2 — O Hacker Formal

ACF2 inverte tudo:


Recurso → Regra → Usuário

Exemplo:


$KEY(PROD)
 UID(DEV01) ALLOW

👉 ACF2 gosta de:

regras
lógica
flexibilidade extrema

⚔️ Capítulo 3 — A Diferença que Ninguém Te Conta

Aqui está o ponto que separa júnior de sênior:

Esses produtos não são equivalentes — eles são modelos mentais diferentes

🧠 RACF pensa em “organização”

Você define estrutura e depois controla acesso.

🧠 TSS pensa em “identidade”

Você dá poder direto ao usuário.

🧠 ACF2 pensa em “lógica”

Você escreve regras e deixa o sistema decidir.

🧨 Capítulo 4 — Onde os Projetos Quebram

Vamos direto ao campo de batalha.

🔥 Caso real 1 — Migração TSS → RACF

Problema:

TSS:
```
DIVISION / DEPARTMENT
```
RACF:
```
GROUP
```

👉 Não existe equivalência direta.

Resultado:

perda de contexto
decisões arquiteturais obrigatórias

🔥 Caso real 2 — ACF2 mal governado

ACF2 permite:

regras complexas
lógica condicional

👉 Sem controle vira:

“ninguém entende mais quem tem acesso a quê”

🔥 Caso real 3 — RACF mal configurado

Erro clássico:


UACC(READ)

👉 Tradução:

você abriu o dataset para meio mundo

🧠 Capítulo 5 — Como Eles Funcionam HOJE (2026)

🔵 RACF hoje

integrado ao z/OS
forte com ferramentas como:
- auditoria
- compliance
padrão de mercado

👉 Usado em:

bancos
governo
grandes corporações

🟢 TSS hoje

ainda muito presente
especialmente em ambientes antigos

👉 Problema:

escassez de profissionais
pressão de custo

🟣 ACF2 hoje

nicho forte
ambientes altamente customizados

👉 Perfil:

organizações com regras complexas

🧩 Capítulo 6 — Easter Eggs de Quem Já Viveu Isso

🥚 1. O mito do “ALL”

No TSS:


ACCESS(ALL)

👉 Pode significar mais do que você imagina…

🥚 2. O clássico “por que isso funcionava antes?”

Resposta:

porque estava no TSS… e ninguém sabia

🥚 3. O fantasma do dataset genérico


PROD.*

👉 Um único profile pode abrir acesso para centenas de datasets.

🥚 4. O usuário com SPECIAL no RACF

👉 Isso aqui é praticamente “root do mainframe”

🧠 Capítulo 7 — Comparação Brutal (sem filtro)

Critério	RACF	TSS	ACF2
Governança	Alta	Média	Alta
Simplicidade	Média	Alta	Baixa
Flexibilidade	Alta	Média	Extremamente alta
Risco operacional	Médio	Médio	Alto
Mercado atual	Dominante	Caindo	Nicho

💣 Capítulo 8 — A Verdade que Poucos Dizem

Não existe “melhor” absoluto.

Existe:

o mais adequado ao seu ambiente
o mais governável pela sua equipe
o menos arriscado para auditoria

🧠 Insight de arquiteto

Se você precisa:

padronização → RACF
simplicidade → TSS
controle extremo → ACF2

🔥 Conclusão — A Guerra Invisível

Enquanto todo mundo fala de:

cloud
APIs
microservices

No mainframe, a pergunta continua sendo a mesma há 40 anos:

“Quem pode fazer o quê?”

E a resposta continua dependendo de um desses três.

☕ Frase final estilo Bellacosa

“Você pode modernizar o COBOL, migrar para APIs, colocar z/OS Connect…
mas se errar no RACF, TSS ou ACF2 — nada disso importa.”

terça-feira, 17 de fevereiro de 2026

🔥💀 COBOL SECURITY LAB — “SEU CICS SOB ATAQUE”

Bellacosa Mainframe lab seu cics sob ataque

🔥💀 COBOL SECURITY LAB — “SEU CICS SOB ATAQUE”

Hands-on prático com CICS + DB2 para aprender segurança na marra

☕ INTRODUÇÃO

Você não vai só aprender…

👉 você vai:

explorar vulnerabilidade
corrigir
validar

💣 exatamente como um atacante faria

🧪 LAB 1 — SQL INJECTION NO DB2

🎯 Objetivo

Mostrar como um COBOL pode ser vulnerável

💻 Código vulnerável


IDENTIFICATION DIVISION.
PROGRAM-ID. LOGIN.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-USER     PIC X(20).
01 WS-PASS     PIC X(20).

PROCEDURE DIVISION.

EXEC SQL
  SELECT NAME INTO :WS-USER
  FROM USERS
  WHERE NAME = :WS-USER
  AND PASSWORD = :WS-PASS
END-EXEC.

💣 Ataque

Input:


' OR '1'='1

💥 Resultado

👉 bypass de autenticação

✅ Correção


IF WS-USER NOT ALPHABETIC
   DISPLAY "INVALID INPUT"
   STOP RUN
END-IF.

💬 Insight

👉 validação é a primeira defesa

🧪 LAB 2 — BUFFER / TAMANHO DE INPUT

🎯 Objetivo

Evitar overflow e dados inválidos

💻 Problema


01 WS-NAME PIC X(10).

Input:


AAAAAAAAAAAAAAAAAAAAAAAAAAAA

💥 Resultado

👉 truncamento / corrupção

✅ Correção


IF LENGTH OF WS-NAME > 10
   DISPLAY "INPUT TOO LONG"
END-IF.

🧪 LAB 3 — HARDCODED PASSWORD

🎯 Objetivo

Eliminar segredo no código

❌ Código


MOVE "DB123456" TO WS-PASS.

💣 Problema

👉 vazamento garantido

✅ Correção

usar RACF
usar external security

👉 RACF

🧪 LAB 4 — VALIDAÇÃO DE COMMAREA (CICS)

🎯 Objetivo

Proteger entrada CICS

💻 Código vulnerável


MOVE DFHCOMMAREA TO WS-DATA.

💣 Problema

👉 dados maliciosos

✅ Correção


IF EIBCALEN = 0
   DISPLAY "NO DATA"
   RETURN
END-IF.

🧪 LAB 5 — LOGGING SEGURO

🎯 Objetivo

Evitar vazamento de dados

❌ Errado


DISPLAY "PASSWORD: " WS-PASS.

💣 Problema

👉 senha em log

✅ Correção


DISPLAY "LOGIN ATTEMPT".

🧪 LAB 6 — CONTROLE DE ACESSO (RACF)

🎯 Objetivo

Simular autorização

💻 Exemplo


CALL 'RACROUTE' USING ...

💬 Resultado

👉 só usuários autorizados acessam

🧪 LAB 7 — INTEGRAÇÃO COM API (RISCO REAL)

🎯 Objetivo

Simular API via CICS

💣 Problema

👉 input externo não confiável

✅ Solução

validar JSON
sanitizar campos

🧪 LAB 8 — TRATAMENTO DE ERRO

🎯 Objetivo

Não expor sistema

❌ Errado


DISPLAY SQLCODE.

💣 Problema

👉 revela estrutura interna

✅ Correto


DISPLAY "ERROR OCCURRED".

🧪 LAB 9 — CONTROLE DE TRANSAÇÃO

🎯 Objetivo

Evitar inconsistência

💻 Uso


EXEC CICS SYNCPOINT
END-EXEC.

💬 Importante

👉 protege integridade

🧪 LAB 10 — SIMULAR ATAQUE REAL

🎯 Objetivo

Mentalidade hacker

💻 Faça

testar inputs inválidos
tentar bypass
observar comportamento

💥 Resultado

👉 descobrir falhas reais

🧠 VISÃO FINAL

Você fez:

ataque
defesa
validação

👉 isso é segurança real

💬 FRASE FINAL

“Mainframe não é seguro por ser forte…
é seguro quando você fecha as portas certas.”

segunda-feira, 16 de fevereiro de 2026

🔥💀 SEU CÓDIGO ESTÁ SEGURO… OU SÓ AINDA NÃO FOI HACKEADO?

Bellacosa Mainframe apresenta segurança em codigo

🔥💀 “SEU CÓDIGO ESTÁ SEGURO… OU SÓ AINDA NÃO FOI HACKEADO?”

Do Cartão Perfurado ao DevSecOps: como as mesmas falhas continuam derrubando sistemas — inclusive o seu

☕ INTRODUÇÃO — O ERRO QUE ATRAVESSOU DÉCADAS

Se você acha que segurança de aplicação é algo “moderno”…

👉 você já começou errado.

Há mais de 20 anos, os mesmos problemas que aparecem hoje na lista da OWASP já existiam.

E o mais assustador:

💣 Eles continuam sendo explorados hoje.

🧠 UM POUCO DE HISTÓRIA (SIM, ISSO COMEÇA NO MAINFRAME)

Antes de:

APIs REST
microservices
cloud

…existia:

🧱 Mainframe + COBOL + CICS + DB2

E adivinha?

👉 Os mesmos problemas já estavam lá:

input sem validação
acesso indevido
dados sensíveis expostos

💀 EASTER EGG HISTÓRICO

Nos anos 70–80, segurança era baseada em:

👉 “ninguém tem acesso físico ao terminal”

Spoiler:

💣 isso não durou muito

🔐 O NASCIMENTO DA SEGURANÇA REAL

Ferramentas como o RACF surgiram para resolver:

quem pode acessar
o que pode acessar
quando pode acessar

👉 primeiro passo para segurança moderna

💣 O PROBLEMA REAL: NÃO É TECNOLOGIA

👉 É comportamento

Hoje temos:

scanners
IA
automação
cloud

E mesmo assim…

💥 vazamentos continuam acontecendo

📊 DADO REAL (que assusta)

Tempo médio para detectar um breach:

👉 ~212 dias

Tempo suficiente para:

invadir
explorar
exfiltrar dados
desaparecer

🔥 OWASP TOP 10 — O MANUAL DO ATACANTE

A OWASP lista os erros mais explorados.

E aqui vai o choque:

👉 quase todos são básicos

💣 EXEMPLO 1 — SQL INJECTION (O DINOSSAURO QUE AINDA MATA)


' OR 1=1 --

👉 isso ainda quebra sistemas hoje

💣 EXEMPLO 2 — XSS (VOCÊ CONFIA NO USUÁRIO?)


<script>stealCookies()</script>

👉 o browser executa
👉 o atacante assume a sessão

💣 EXEMPLO 3 — DEPENDÊNCIAS VULNERÁVEIS

Você escreve:

👉 20% do código

O resto?

👉 bibliotecas externas 😬

🛠️ DEVSECOPS — A VIRADA DE JOGO

Antes:

👉 segurança era responsabilidade de outro time

Hoje:

👉 “You build it, you run it… and you secure it.”

🔄 PIPELINE MODERNO


code → scan → test → deploy → monitor

Ferramentas:

SAST (ex: análise estática)
DAST (ataque simulado)
SCA (dependências)
runtime protection

🧪 MÃO NA MASSA (O QUE VOCÊ PRATICOU)

Você fez:

🔍 SAST

analisou código sem rodar

🌐 DAST

atacou a aplicação com ferramentas

📦 SCA

descobriu vulnerabilidade em libs

🔐 Secrets

saiu do hardcode → Vault

🐳 Docker Security

corrigiu imagem vulnerável

👉 isso é exatamente o que empresas fazem hoje

💀 ERRO CLÁSSICO (QUE DERRUBA EMPRESA)


password = "123456"

👉 parece inofensivo

👉 vira incidente milionário

🧠 A VERDADE QUE NINGUÉM TE CONTA

👉 Segurança não falha por falta de ferramenta

👉 Segurança falha por:

pressa
ignorância
negligência

🔥 CURIOSIDADE (QUE MUDA SUA VISÃO)

O maior ataque da história recente (Log4j):

👉 veio de uma biblioteca

Não do código principal

🚀 DO DEV AO ENGENHEIRO DE SEGURANÇA

Depois desse conhecimento, você não é mais só dev:

👉 você entende:

como atacar
como defender
onde estão os riscos

🧱 E O COBOL NISSO TUDO?

Tudo isso se aplica em:

CICS
DB2
APIs via z/OS Connect

👉 Mainframe não é imune
👉 ele só é mais disciplinado

💬 FRASE PRA GRAVAR

“Você não precisa ser hackeado para estar vulnerável…
basta ignorar o básico.”

🔥 CONCLUSÃO (SEM FILTRO)

👉 Se você não:

valida input
protege secrets
escaneia dependências
monitora

💣 seu sistema já está em risco

🚀 CHAMADA FINAL

Agora você tem duas opções:

👉 continuar escrevendo código
ou
👉 começar a proteger sistemas

segunda-feira, 2 de abril de 2018

IBM Mainframe Discovery : Capítulo IV — A Sala dos Cofres Cósmicos

Bellacosa Mainframe apresenta o ibm mainframe parte IV

☕ Um Café no Bellacosa Mainframe

Capítulo IV — A Sala dos Cofres Cósmicos

Segurança no IBM Z: Por Que os Guardiões Dormem Tranquilos

PRIMEIRA REGRA DA SEGURANÇA INTERGALÁCTICA

Se alguém disser:

"Nossa nave nunca será invadida."

...desconfie imediatamente.

Porque o Universo possui uma característica curiosa.

Ele é povoado por três tipos de seres.

Os inteligentes.

Os curiosos.

E os curiosamente inteligentes.

Infelizmente, o terceiro grupo costuma dedicar boa parte da vida tentando descobrir como entrar onde não foi convidado.

Foi pensando nesses exploradores inconvenientes que nasceu uma das arquiteturas de segurança mais sofisticadas da história da computação.

Bem-vindo ao setor mais protegido da nave IBM Z.

A Fortaleza Invisível

Imagine uma gigantesca cidade espacial.

Nela existem:

Hospitais.

Bancos.

Laboratórios.

Centrais de energia.

Hangar militar.

Sala do comandante.

Agora imagine que todas essas instalações estão abertas.

Sem portas.

Sem crachás.

Sem vigilância.

Quanto tempo levaria até surgir o primeiro desastre?

Provavelmente menos tempo do que um operador leva para digitar:

TSO LOGON

Segurança Não Começa na Senha

Esse talvez seja o maior erro cometido por iniciantes.

Pensam que segurança significa:

senha.

Na verdade...

senha é apenas a campainha da porta.

O verdadeiro sistema de segurança está muito além.

Ele envolve:

identidade.

autorização.

criptografia.

hardware.

isolamento.

auditoria.

integridade.

No IBM Z, segurança nunca foi um programa instalado depois.

Ela faz parte da própria arquitetura.

O Bairro Proibido

Imagine nossa nave dividida em milhares de compartimentos.

Cada porta possui uma cor diferente.

Você recebeu uma chave azul.

Isso significa que pode abrir:

portas azuis.

Nada mais.

Mesmo que descubra onde está a sala do capitão...

...a porta simplesmente não abrirá.

Essa é exatamente a filosofia do Hardware Storage Key Protection.

As Chaves da Memória

Aqui encontramos um recurso extraordinário.

Cada bloco de memória de 4 KB recebe uma chave de proteção.

Quando um programa tenta acessar esse bloco...

o hardware pergunta:

— Sua chave corresponde à chave desta área?

Se sim...

entrada permitida.

Caso contrário...

acesso negado.

Tudo isso acontece diretamente no hardware.

Sem depender do sistema operacional.

Segundo Spruth, essa proteção praticamente impede que um programa comum sobrescreva áreas privilegiadas da memória, reduzindo drasticamente riscos como buffer overflows em regiões críticas do sistema.

O Guarda Nem Precisa Pensar

Observe algo interessante.

O processador não pergunta:

"Será que esse programa é confiável?"

Ele apenas compara chaves.

É rápido.

Determinístico.

Matemático.

Não existe interpretação.

Isso torna a segurança extremamente eficiente.

O Labirinto dos Buffer Overflows

Imagine uma biblioteca.

Cada sala possui paredes extremamente resistentes.

Você pode encher uma estante de livros.

Mas ela nunca atravessará a parede para invadir a sala vizinha.

Foi exatamente essa ideia que inspirou a proteção por Storage Keys.

Em muitas plataformas, erros de programação permitiram durante décadas que um processo escapasse de sua área de memória.

No IBM Z isso sempre foi muito mais difícil.

O Cofre Dentro do Cofre

Agora imagine que existe uma sala secreta.

Dentro dela há outro cofre.

Dentro desse cofre existe uma pequena caixa.

Dentro da caixa está a chave do banco da galáxia.

Parece exagero?

Não para quem administra bilhões de dólares diariamente.

É aqui que entra a criptografia do IBM Z.

Dois Magos da Criptografia

O relatório apresenta dois personagens extremamente importantes.

O primeiro é:

CPACF

(CP Assist for Cryptographic Functions)

Ele vive dentro da própria CPU.

Sua missão é acelerar algoritmos criptográficos.

O segundo é:

Crypto Express

Uma placa especializada.

Muito mais poderosa.

Muito mais protegida.

Cada uma possui responsabilidades diferentes.

Enquanto o CPACF acelera operações criptográficas diretamente no processador, o Crypto Express executa funções avançadas envolvendo gerenciamento seguro de chaves, assinaturas digitais, geração de números aleatórios e criptografia assimétrica.

A Chave Que Nunca Sai do Cofre

Este talvez seja o conceito mais elegante de todo o capítulo.

O nome é:

Master Key.

Imagine um rei.

Ele nunca sai do castelo.

Nunca participa das batalhas.

Nunca atravessa fronteiras.

Todas as outras chaves viajam.

Mas o rei permanece protegido.

No IBM Z acontece exatamente isso.

A Master Key permanece armazenada dentro do hardware criptográfico.

Ela nunca aparece em memória.

Nunca vai para disco.

Nunca é enviada pela rede.

Segundo o relatório, apenas cópias criptografadas das chaves de aplicação circulam pelo sistema; sua descriptografia ocorre exclusivamente dentro do coprocesso seguro.

O Cofre Autodestrutivo

Agora imagine que alguém tente abrir esse cofre usando uma furadeira.

Ou calor.

Ou eletricidade.

Ou qualquer outro ataque físico.

O que acontece?

O cofre destrói imediatamente seu segredo.

Parece filme.

Mas é engenharia.

As placas Crypto Express utilizam módulos resistentes à violação física (Tamper Resistant Security Module).

Caso detectem tentativa de invasão, podem apagar automaticamente as chaves armazenadas.

A Grande Biblioteca das Permissões

Até agora falamos sobre hardware.

Mas alguém precisa decidir:

Quem pode fazer o quê?

É aqui que encontramos dois dos personagens mais famosos do z/OS.

SAF — O Porteiro da Nave

Imagine um enorme edifício.

Em cada porta existe um segurança.

Mas esse segurança não toma decisões.

Ele apenas pergunta:

— Posso deixar esta pessoa entrar?

Quem responde?

Outro departamento.

Esse segurança chama-se:

SAF.

Security Authorization Facility.

Ele identifica eventos de segurança e encaminha a decisão ao mecanismo responsável pela autorização.

RACF — O Conselho Galáctico

O verdadeiro juiz chama-se:

RACF

(Resource Access Control Facility).

Imagine um gigantesco livro de regras.

Ele contém milhões de decisões.

Quem pode acessar:

arquivos.

programas.

transações.

impressoras.

bancos.

datasets.

comandos.

Cada tentativa de acesso consulta esse conjunto de perfis e regras.

Spruth observa que o RACF utiliza perfis e mecanismos de autorização extremamente granulares, tornando-se um dos pilares da segurança no z/OS.

APF — O Conselho dos Mestres

Existe um erro muito comum.

Pensar que todo programa privilegiado deveria ter acesso total.

No IBM Z isso seria considerado um péssimo projeto.

Surge então o:

Authorized Program Facility

APF.

Imagine uma nave.

Alguns oficiais podem abrir a sala de máquinas.

Outros podem acessar o hangar.

Pouquíssimos chegam ao núcleo do reator.

Cada um recebe apenas os privilégios necessários.

Nada além disso.

Segundo Spruth, o APF funciona como um guardião da integridade do sistema, permitindo que apenas programas autorizados utilizem determinados serviços privilegiados do z/OS.

O Pecado Mortal: Dar Poder Demais

Em muitos sistemas operacionais existe apenas:

Administrador.

Usuário.

Fim.

No IBM Z a filosofia é diferente.

Autorizações são extremamente específicas.

Esse princípio ficou conhecido muitos anos depois como:

Princípio do Menor Privilégio.

Curiosamente...

o Mainframe já vivia isso muito antes do termo virar moda.

A Cidade Que Nunca Dorme

Imagine bilhões de habitantes.

Todos entrando.

Saindo.

Movimentando dinheiro.

Consultando informações.

Transferindo recursos.

Como saber quem fez cada ação?

Resposta:

auditoria.

Embora o relatório foque principalmente em SAF, RACF e APF, toda essa arquitetura trabalha em conjunto com mecanismos de registro e rastreabilidade do z/OS, permitindo acompanhar eventos relevantes de segurança.

Porque segurança sem auditoria é apenas esperança.

Um Curioso Comentário de Spruth

Há uma frase no relatório que chama atenção.

O autor comenta que não conhecia casos de infecção por vírus ou ataques bem-sucedidos comprometendo sistemas z/OS na época em que escreveu o documento.

Hoje sabemos que nenhum sistema deve ser considerado absolutamente imune.

As ameaças evoluem constantemente.

Ainda assim, o histórico do IBM Z continua sendo um dos mais sólidos da indústria, justamente porque sua arquitetura foi concebida com isolamento, controle de acesso e defesa em profundidade.

O Que Mudou Desde 2010?

Desde a publicação do relatório, o ecossistema IBM Z ganhou novos recursos importantes:

algoritmos criptográficos mais modernos;
suporte ampliado para curvas elípticas e TLS atualizado;
integração com autenticação multifator;
criptografia preparada para desafios futuros;
Secure Execution para cargas Linux;
gerenciamento avançado de certificados;
proteção de APIs;
integração com ambientes híbridos e Zero Trust.

Mas observe algo curioso.

Os princípios fundamentais permanecem exatamente os mesmos.

A Filosofia dos Antigos Engenheiros

Os engenheiros do System/360 pareciam seguir uma máxima curiosa.

Não confie em ninguém.

Nem no usuário.

Nem no operador.

Nem no programa.

Nem no hardware.

Nem no futuro.

Cada camada protege a próxima.

Cada componente verifica o anterior.

Cada privilégio precisa ser justificado.

É quase como construir uma nave supondo que, em algum momento, alguém inevitavelmente tentará entrar onde não deveria.

Curiosidades do Diário de Bordo

🔐 O IBM Z incorporou mecanismos de proteção em hardware décadas antes de muitos conceitos modernos de segurança se popularizarem.

🛡️ Storage Keys, APF, SAF e RACF formam uma cadeia de proteção em camadas, onde cada elemento tem uma função específica.

🔑 A Master Key jamais precisa sair do hardware criptográfico, reduzindo drasticamente o risco de exposição.

🌌 Segurança, no universo IBM Z, nunca foi tratada como um produto adicional. Ela faz parte da própria fundação da arquitetura.

Diário de Bordo do Padawan COBOL

Antes de deixar o setor de segurança da nave, registre estas coordenadas:

✅ Segurança começa na arquitetura, não na tela de login.

✅ Quanto menos privilégios um programa possuir, menor será o impacto de uma eventual falha.

✅ Criptografia eficiente depende tanto da proteção das chaves quanto dos algoritmos utilizados.

✅ A melhor defesa não é impedir que todos tentem entrar; é construir um sistema onde cada porta saiba exatamente quem pode atravessá-la.

No próximo capítulo seguiremos para um dos compartimentos mais fascinantes de toda a nave: o Subsistema de Entrada e Saída (I/O). Descobriremos por que, enquanto muitos computadores fazem a CPU esperar pelos discos, o IBM Z decidiu entregar essa missão a uma verdadeira frota de especialistas — transformando o I/O em uma operação digna de uma logística interplanetária.

☕ 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.