✨ 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 criptografia. Mostrar todas as mensagens

quinta-feira, 9 de abril de 2026

🔥 SEU MAINFRAME ESTÁ SEGURO… OU SÓ PARECE?

Bellacosa Mainframe em um pequeno bate papo sobre segurança racf saf

🔥 SEU MAINFRAME ESTÁ SEGURO… OU SÓ PARECE?

A Verdade Crua da Segurança no z/OS (Do RACF ao Crypto Express)

☕ Introdução — Um Café com a Realidade

Se você acha que segurança no mainframe é “coisa do passado”, deixa eu te dar um choque de realidade:

O z/OS é um dos ambientes mais seguros do planeta — mas só quando bem configurado.

Porque na prática?

👉 O problema nunca foi a tecnologia
👉 O problema sempre foi quem configura

E é exatamente aqui que começa nossa jornada.

🕰️ Um pouco de história (e por que isso importa)

Nos anos 70, quando surgiram os primeiros sistemas corporativos massivos, a IBM percebeu algo:

“Se todo mundo acessa tudo… uma hora dá ruim.”

Nasce então o conceito de controle centralizado de acesso, que evolui para:

RACF
SAF
E todo o ecossistema de segurança do z/OS

Enquanto o mundo distribuído ainda estava descobrindo autenticação…

👉 O mainframe já tinha segurança granular por recurso

🧠 O Coração da Segurança: SAF + RACF

Pensa nisso como um fluxo batch:

Usuário → SAF → RACF → decisão (ALLOW / DENY)

🧩 Quem faz o quê?

SAF → interface (o “porteiro”)
RACF → decisão (o “juiz”)

💡 Easter egg Bellacosa:

SAF nunca decide nada… ele só “encaminha o problema” 😄

🔐 O Mandamento Supremo: Least Privilege

Se você tiver que lembrar de UMA coisa:

“Dê o mínimo necessário — nunca o máximo possível.”

Exemplo clássico:

Admin RACF → gerencia segurança
Storage admin → só mexe em dataset

👉 Separação + privilégio mínimo = sistema saudável

💣 O ERRO QUE MAIS DERRUBA AMBIENTE

❌ PROTECTALL desligado

Sem isso:

Dataset sem perfil → acesso liberado 😱

👉 Simples assim.
👉 Sem perfil = sem segurança

💡 Curiosidade:
Muitos incidentes em mainframe não são ataques…
São configuração mal feita.

🔥 Criptografia no z/OS: Outro nível

Enquanto muita gente ainda “liga TLS”, o z/OS já faz:

🔐 Pervasive Encryption

Dados em disco
Dados em trânsito
Dados protegidos sem mudar aplicação

🧬 A Hierarquia das Chaves (isso cai MUITO!)

Master Key → protege → Operational Key → protege → Data

Tipos importantes:

Master Keys → topo da cadeia
Symmetric → performance
Asymmetric → troca segura
Operational → uso diário

💡 Easter egg:

Se perder a master key… acabou o jogo.

⚙️ ICSF — O Tradutor da Criptografia

Aplicação nunca fala direto com hardware.

Ela fala com:

👉 ICSF

Que fala com:

👉 CPACF / Crypto Express

🛡️ Níveis de proteção (isso é ouro de prova)

Nível	Segurança
Clear Key	😬
Protected Key	👍
Secure Key	🔥🔥🔥

👉 Secure Key = dentro do hardware (Crypto Express)

💻 APF — Quem pode ser “superpoderoso”

Nem todo programa pode rodar com privilégio.

👉 Só quem está no APF

Programa fora do APF → sem privilégio
Programa no APF → modo supervisor

💡 Isso evita:

código malicioso
erro catastrófico

🌐 Rede no z/OS — Não é só TCP/IP

z/OS Communications Server

TCP/IP (moderno)
SNA (legado que ainda vive 😄)

Segurança:

TLS → camada transporte
IPSec → VPN (nível rede)

📊 SMF — O “log que conta tudo”

Se algo aconteceu:

👉 O SMF sabe

Mas atenção:

Nada é logado automaticamente se você não configurar

🧪 Caso real (estilo Bellacosa)

Empresa com:

RACF instalado
Criptografia ativa
Auditoria configurada

Mas…

❌ PROTECTALL desligado
❌ UACC READ em datasets críticos

Resultado?

👉 Vazamento interno
👉 Sem ataque externo

💡 Moral:

Segurança não é tecnologia — é configuração.

🧠 Mentalidade Mainframe

Enquanto no mundo distribuído se fala:

“vamos adicionar segurança”

No mainframe é:

“vamos NÃO remover a segurança”

🔥 Frases pra tatuar no cérebro

“SAF conecta, RACF decide”
“Sem PROTECTALL, está exposto”
“Sem chave, não há segurança”
“ALL = mostra tudo”
“SPECIAL = poder total (cuidado!)”

🏁 Conclusão — A Verdade Final

O z/OS não é seguro por acaso.

Ele é seguro porque:

Foi projetado assim
Evoluiu assim
Exige disciplina

Mas…

Um mainframe mal configurado é tão vulnerável quanto qualquer outro sistema.

☕ Fechamento estilo Bellacosa

Segurança no mainframe não é só técnica.

É filosofia.

É controle.

É respeito ao sistema.

E principalmente:

É saber que o perigo não está fora… está dentro da configuração.

segunda-feira, 5 de janeiro de 2026

🔥 SEU RACF ESTÁ TE PROTEGENDO… OU TE TRAINDO?

Bellacosa Mainframe em uma conversa sobre segurança mainframe

🔥 SEU RACF ESTÁ TE PROTEGENDO… OU TE TRAINDO?

🧪 LAB PRÁTICO — Do Acesso Liberado ao Controle Total no z/OS

☕ Introdução — Bem-vindo ao caos controlado

Hoje você não vai só aprender…

👉 Você vai quebrar a segurança do sistema
👉 E depois consertar como um verdadeiro admin raiz

💡 Estilo Bellacosa:

“Se você nunca viu um sistema inseguro… você ainda não entendeu segurança.”

🎯 Objetivo do LAB

Você vai:

❌ Criar um cenário inseguro (sem proteção)
🔍 Explorar a falha
🛡️ Corrigir com RACF
🔐 Validar segurança

⚠️ Cenário

Você é admin e recebe:

“Precisamos liberar rápido o dataset PROD.FINANCEIRO.*”

😈 Spoiler: isso vai dar ruim.

🧪 FASE 1 — Criando o problema (sim, de propósito)

1️⃣ Criar dataset “sensível”

//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=PROD.FINANCEIRO.DADOS,
//      DISP=(NEW,CATLG),
//      SPACE=(TRK,(1,1)),
//      DCB=(RECFM=FB,LRECL=80,BLKSIZE=800)

2️⃣ NÃO criar perfil RACF

👉 Sim… você vai deixar sem proteção

💡 Easter egg:

Isso acontece mais em produção do que você imagina 😅

3️⃣ Testar acesso com outro usuário

TSO LISTDS 'PROD.FINANCEIRO.DADOS'

👉 Se PROTECTALL estiver OFF:

💥 Acesso permitido

💣 Resultado

Dataset crítico → sem perfil → acesso liberado 😱

🧠 REFLEXÃO

Você acabou de:

Criar uma falha real
Simular um incidente comum

👉 E ninguém hackeou nada

🛡️ FASE 2 — Corrigindo como profissional

1️⃣ Criar perfil de dataset

RDEFINE DATASET PROD.FINANCEIRO.* UACC(NONE)

2️⃣ Permitir acesso controlado

PERMIT PROD.FINANCEIRO.* CLASS(DATASET) ID(FINUSR) ACCESS(READ)

3️⃣ Ativar proteção

SETROPTS RACLIST(DATASET) REFRESH

4️⃣ (CRÍTICO) Ativar PROTECTALL

SETROPTS PROTECTALL

💥 Agora sim:

👉 Dataset sem perfil = acesso negado

🔍 FASE 3 — Validando segurança

Teste novamente:

TSO LISTDS 'PROD.FINANCEIRO.DADOS'

👉 Resultado esperado:

ICH408I USER NOT AUTHORIZED

🔥 Agora você está protegido

⚙️ FASE 4 — Explorando comando “ALL”

LD DA('PROD.FINANCEIRO.*') ALL

👉 Vai mostrar:

Dono
Permissões
UACC
Detalhes completos

💡 Frase pra vida:

“ALL = mostra tudo. Sem ALL = você está voando no escuro.”

🔐 FASE 5 — Elevando nível com SPECIAL

Criar usuário admin

ADDUSER ADMIN1 SPECIAL

👉 Esse usuário pode:

Alterar tudo
Criar perfis
Controlar segurança

⚠️ Cuidado:

SPECIAL = poder total

⚙️ FASE 6 — Simulando programa privilegiado (APF)

👉 Imagine:

Um programa precisa acessar memória sensível

Sem APF:

❌ Falha

Com APF:

✅ Executa com privilégio

💡 Curiosidade:

Muitos ataques internos exploram programas mal autorizados no APF

🔐 FASE 7 — Criptografia (visão prática)

👉 Fluxo real:

App → ICSF → Crypto Express → dado protegido

Você não vê… mas está acontecendo.

📊 FASE 8 — Auditoria com SMF

👉 Tudo que você fez pode ser registrado:

Acesso ao dataset
Tentativas negadas
Alterações

💡 Mas só se estiver configurado 😉

🧠 Easter Eggs do LAB

PROTECTALL OFF = caos silencioso
UACC(READ) mal usado = vazamento
SPECIAL demais = bomba relógio
Sem log = sem prova

🏁 Checklist final

Você aprendeu:

✔ Criar falha real
✔ Corrigir com RACF
✔ Controlar acesso
✔ Validar segurança
✔ Entender impacto

☕ Conclusão estilo Bellacosa

Segurança no mainframe não é:

ferramenta
comando
checklist

É:

Mentalidade.

Porque no final…

👉 O sistema nunca erra
👉 Quem erra é quem configura

🔥 Desafio final

Responda:

Seu ambiente hoje está protegido…
ou só parece?

quinta-feira, 30 de março de 2023

Os 100 Comandos Mais Importantes do CMD.EXE e da Herança MS-DOS no Windows Parte III

Bellacosa Mainframe e comandos ms-dos no windows parte 3

Os 100 Comandos Mais Importantes do CMD.EXE e da Herança MS-DOS no Windows

Parte 3 – Comandos 51 a 75

Administração Avançada, Segurança, Registro do Windows e Gerenciamento do Sistema

Introdução

Após explorar os comandos fundamentais de navegação, gerenciamento de arquivos, rede e diagnóstico nas partes anteriores, chegamos a uma das áreas mais poderosas do CMD.EXE: a administração avançada do sistema operacional Windows.

Os comandos desta seção são amplamente utilizados por administradores de sistemas, analistas de suporte N2 e N3, profissionais de infraestrutura, especialistas em segurança da informação e equipes de Data Center. Eles permitem controlar serviços, agendamentos, permissões NTFS, criptografia, compartilhamentos, usuários conectados, Registro do Windows e diversos componentes internos do sistema operacional.

Muitos desses comandos exigem privilégios administrativos e devem ser utilizados com cautela, pois alterações incorretas podem impactar diretamente a estabilidade do ambiente.

51. SCHTASKS

Nome Completo

Scheduled Tasks

Função

Criar, gerenciar e remover tarefas agendadas no Windows.

Sintaxe

schtasks

Exemplo

schtasks /query

Criar tarefa

schtasks /create /sc daily /tn Backup /tr backup.bat

Aplicações

Backups automáticos.
Relatórios periódicos.
Rotinas administrativas.

52. GPRESULT

Nome Completo

Group Policy Result

Função

Exibir políticas de grupo aplicadas ao computador e usuário.

Sintaxe

gpresult

Exemplo

gpresult /r

Utilidade

Diagnóstico de GPO.
Active Directory.
Auditorias corporativas.

53. WEVTUTIL

Nome Completo

Windows Event Utility

Função

Gerenciar logs de eventos do Windows.

Sintaxe

wevtutil

Exemplo

wevtutil el

Aplicações

Auditoria.
Segurança.
Forense digital.

54. VER

Nome Completo

Version

Função

Exibir a versão do Windows.

Sintaxe

ver

Exemplo

ver

Utilidade

Identificar rapidamente a versão do sistema operacional.

55. HOSTNAME

Função

Exibir o nome do computador.

Sintaxe

hostname

Exemplo

hostname

Aplicações

Inventário.
Administração de rede.
Scripts corporativos.

56. WHOAMI

Nome Completo

Who Am I

Função

Mostrar usuário atualmente autenticado.

Sintaxe

whoami

Exemplo

whoami /all

Informações Exibidas

Usuário.
SID.
Grupos.
Privilégios.

57. TIME

Função

Exibir ou alterar horário do sistema.

Sintaxe

time

Exemplo

time 14:30

Aplicações

Sincronização.
Testes.
Administração.

58. DATE

Função

Exibir ou alterar data do sistema.

Sintaxe

date

Exemplo

date 20-12-2025

59. SET

Função

Exibir e criar variáveis de ambiente.

Sintaxe

set

Exemplo

set nome=Bellacosa

Utilidade

Fundamental para scripts Batch.

60. PATH

Função

Visualizar ou modificar caminhos de execução.

Sintaxe

path

Exemplo

path %path%;C:\Ferramentas

Aplicações

Desenvolvimento.
Administração.
Automação.

61. REG

Nome Completo

Registry Console Tool

Função

Gerenciar o Registro do Windows.

Sintaxe

reg

Exemplo

reg query HKLM

Aplicações

Administração.
Automação.
Inventário.

62. REG QUERY

Função

Consultar chaves e valores do Registro.

Sintaxe

reg query

Exemplo

reg query HKLM\Software

Utilidade

Verificação de configurações.

63. REG ADD

Função

Adicionar chaves e valores ao Registro.

Sintaxe

reg add

Exemplo

reg add HKCU\Teste /v Exemplo /t REG_SZ /d Bellacosa

Atenção

Alterações incorretas podem comprometer o sistema.

64. REG DELETE

Função

Excluir chaves ou valores.

Sintaxe

reg delete

Exemplo

reg delete HKCU\Teste

Aplicação

Limpeza e automação.

65. TAKEOWN

Nome Completo

Take Ownership

Função

Assumir posse de arquivos e diretórios.

Sintaxe

takeown

Exemplo

takeown /f arquivo.txt

Utilidade

Recuperação de permissões.

66. ICACLS

Nome

Integrity Control Access Control Lists

Função

Gerenciar permissões NTFS.

Sintaxe

icacls

Exemplo

icacls arquivo.txt /grant Administrators:F

Aplicações

Segurança.
Controle de acesso.
Auditoria.

67. CIPHER

Função

Gerenciar criptografia EFS.

Sintaxe

cipher

Exemplo

cipher /e Dados

Recursos

Criptografia.
Descriptografia.
Limpeza segura.

68. COMPACT

Função

Compactar arquivos NTFS.

Sintaxe

compact

Exemplo

compact /c relatorio.txt

Benefícios

Economia de espaço em disco.

69. OPENFILES

Função

Listar arquivos abertos remotamente.

Sintaxe

openfiles

Exemplo

openfiles /query

Aplicações

Administração de servidores.
Auditoria.

70. QUERY USER

Função

Exibir usuários conectados.

Sintaxe

query user

Exemplo

query user

Utilidade

Monitoramento de sessões.

71. QUERY SESSION

Função

Mostrar sessões ativas.

Sintaxe

query session

Exemplo

query session

Aplicações

Terminal Services.
Remote Desktop.

72. LOGOFF

Função

Encerrar sessões de usuário.

Sintaxe

logoff

Exemplo

logoff 2

Aplicação

Administração remota.

73. SHUTDOWN

Função

Desligar ou reiniciar computadores.

Sintaxe

shutdown

Exemplos

Desligar:

shutdown /s /t 0

Reiniciar:

shutdown /r /t 0

Modo avançado:

shutdown /r /o

Aplicações

Manutenção.
Atualizações.
Administração remota.

74. RECOVER

Função

Recuperar dados legíveis de discos danificados.

Sintaxe

recover

Exemplo

recover arquivo.txt

Utilidade

Tentativa de recuperação de dados.

75. LABEL

Função

Exibir ou alterar o rótulo de volumes.

Sintaxe

label

Exemplo

label D: BACKUP_2025

Aplicações

Organização de discos.
Inventário.
Administração de armazenamento.

Conclusão da Parte 3

Os comandos de 51 a 75 representam um salto importante em relação aos comandos básicos do CMD.EXE. Eles permitem administrar serviços, gerenciar políticas corporativas, manipular o Registro do Windows, controlar permissões NTFS, criptografar arquivos, monitorar sessões de usuários e executar tarefas avançadas de manutenção.

Dominar esse conjunto de ferramentas é essencial para profissionais que trabalham com infraestrutura Microsoft, Active Directory, servidores Windows, virtualização e segurança da informação.

Na Parte 4 serão apresentados os comandos 76 a 100, abordando automação, scripts Batch, produtividade, inicialização do sistema, gerenciamento de discos, configuração de boot e ferramentas avançadas para administradores experientes.

quinta-feira, 12 de setembro de 2019

💻 Bellacosa Mainframe Blog — IBM System z15: O Mainframe da Era da Confiança, Privacidade e Nuvem Híbrida

💻 Bellacosa Mainframe Blog — IBM System z15: O Mainframe da Era da Confiança, Privacidade e Nuvem Híbrida

🕰️ Ano de lançamento

2019 — O IBM System z15 foi anunciado em 12 de setembro de 2019, sucedendo o z14 como o novo pilar da estratégia “Enterprise Hybrid Cloud” da IBM.
Com ele, a Big Blue reforçou sua visão de dados protegidos, mobilidade controlada e resiliência operacional — pilares fundamentais da economia digital moderna.

🧩 Modelos disponíveis

IBM z15 Model T01 (2019) — Modelo de alta capacidade, voltado a grandes corporações, com múltiplos drawers e interconexões de alta velocidade.
IBM z15 Model T02 (2020) — Versão “compacta”, pensada para ambientes híbridos e datacenters modernos, compatível com racks padrão de 19”.

Ambos os modelos permitem workloads mistos (z/OS, Linux on Z, z/VM, z/VSE, z/TPF) e são totalmente integráveis a soluções Red Hat OpenShift e IBM Cloud Pak.

⚙️ CPU e arquitetura

Processador: IBM z15 Core Chip, tecnologia de 7 nanômetros
Clock: até 5.2 GHz
Cores por sistema: até 190 processadores físicos
Memória máxima: 40 TB de RAM
Criptografia: Pervasive Encryption com IBM Secure Execution e aceleração por hardware nativo
Arquitetura: nova geração da z/Architecture com suporte aprimorado a SMT-2, instruções vetoriais e compressão acelerada

O z15 trouxe uma revisão de design no cache L2/L3 e no pipeline de execução, entregando até 25% mais performance por core em cargas mistas de CICS, DB2 e WebSphere.

🧠 Versão do z/OS compatível

z/OS 2.4 (lançada junto com o z15)
Compatibilidade retroativa: z/OS 2.3, z/VM 7.1, z/VSE 6.2 e Linux on Z (RHEL, SUSE, Ubuntu)

🧬 Introdução técnica

O z15 representou um salto para o mundo da privacidade de dados e integração em nuvem.
Ele foi o primeiro mainframe com suporte nativo a Data Privacy Passports, um sistema de controle de dados que acompanha a informação mesmo fora do mainframe.

Além disso, trouxe o conceito de:

Instant Recovery: reinicializações até 2x mais rápidas após manutenções planejadas.
Data Privacy Passports: controle e auditoria de dados em múltiplas plataformas.
IBM Secure Execution for Linux: isolamento criptográfico de VMs Linux diretamente no hardware.
z/OS Container Extensions (zCX): execução de contêineres Docker sob o z/OS, sem precisar migrar workloads.

🔁 O que muda em relação ao System z14

Recurso	System z14	System z15	Evolução
Litografia	14 nm	7 nm	Duplicação da densidade e eficiência
Cores Máximos	170	190	+12% de capacidade de processamento
Memória Máx.	32 TB	40 TB	Aumento de 25%
Criptografia	On-chip	Secure Execution e Privacy Passports	Criptografia com controle global
Recuperação	IPL padrão	Instant Recovery	Redução do downtime em até 50%
Cloud	zCX básico	Red Hat OpenShift e IBM Cloud Pak	Cloud híbrida corporativa

🧾 Curiosidades

O codinome interno do projeto foi “Poughkeepsie Eagle”, em homenagem à cidade que abriga o centro histórico de desenvolvimento dos mainframes da IBM.
Foi o primeiro mainframe a integrar Red Hat OpenShift oficialmente, após a aquisição da Red Hat pela IBM.
A IBM focou o lançamento no conceito de “Freedom of Choice” — a liberdade de mover workloads entre on-premises e cloud sem perder segurança nem governança.
O z15 é capaz de criptografar até 1 trilhão de transações por dia sem perda perceptível de performance.

🧠 Dica técnica Bellacosa

👉 Habilite o Instant Recovery no IPL do sistema.
Durante janelas de manutenção, o z15 usa “Capacity Boost” automático — um recurso que aloca temporariamente mais poder de CPU e I/O durante a recuperação, sem custo adicional de licenciamento.
Isso é ouro para workloads críticos CICS e DB2 que exigem retomada imediata.

👉 Explore o Data Privacy Passport Manager (DPPM) — um serviço que acompanha os dados criptografados até fora do mainframe, protegendo a conformidade com normas como GDPR e LGPD.

🔍 Nota técnica

Cada drawer do z15 possui até 12 processadores e 4 TB de memória, interconectados via A-Bus de altíssima largura de banda.
A compressão de dados (zEDC) foi incorporada diretamente ao hardware do core, reduzindo custos de CPU em até 30% em workloads de storage.
O z15 entrega até 14% de melhoria no throughput de criptografia comparado ao z14, especialmente em ambientes com TLS e APIs REST via z/OS Connect EE.

🏁 Resumo técnico

Item	Detalhe
Ano	2019 (T01) / 2020 (T02)
Modelos	T01, T02
CPU	z15 core chip (7 nm, até 190 cores)
Memória Máx.	40 TB
z/OS	2.4 (nativo), 2.3 (compatível)
Destaques	Privacidade global, Instant Recovery, Cloud híbrida
Codinome interno	Poughkeepsie Eagle

🧭 História e legado

O System z15 consolidou o papel do mainframe como plataforma de nuvem corporativa segura.
Ele foi o elo entre o mundo tradicional do z/OS e o ecossistema Red Hat OpenShift, abrindo as portas para containers, microserviços e aplicações cognitivas — sem sacrificar a robustez de 60 anos de confiabilidade IBM Z.

O z15 preparou o terreno para o z16, que em 2022 trouxe IA on-chip e computação quântica assistida — um salto digno da próxima geração.

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.