Translate

Mostrar mensagens com a etiqueta criptografia. Mostrar todas as mensagens
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ívelSeguranç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?

 

sexta-feira, 9 de março de 2012

🔢 39, 4649 e 893 — Numerologia ninja: quando o Japão escreve mensagens com números

 

goroawase numeros transmitem mensagens

🔢 39, 4649 e 893 — Numerologia ninja: quando o Japão escreve mensagens com números

(Analisado por um mainframeiro curioso, ao melhor estilo Bellacosa Mainframe)

Quem vem do mundo mainframe sabe: número nunca é só número. Pode ser return code, abend, offset, porta, dataset. No Japão, essa lógica foi elevada a arte cultural. Existe um hábito curioso e delicioso chamado 語呂合わせ (goroawase), onde números são usados para representar palavras e mensagens inteiras, baseadas na leitura fonética dos algarismos.

É como escrever um e-mail inteiro usando apenas códigos — coisa que qualquer mainframeiro raiz respeita.


goroawase obrigado san kyu

🧠 O que é Goroawase?

Goroawase é um jogo de palavras que usa:

  • leituras japonesas dos números (kun’yomi),

  • leituras chinesas (on’yomi),

  • abreviações informais,

  • e muita criatividade cultural.

Resultado? Mensagens cifradas, rápidas, emocionais e cheias de contexto.


⭐ Os números mais usados (e o que realmente querem dizer)

❤️ 39 — サンキュー (san kyū)

  • Significado: Obrigado / Thank you

  • Origem:

    • 3 = san

    • 9 = kyū

  • Uso comum: Mensagens, placas, idols, fãs, despedidas

🎌 Curiosidade: O dia 9 de março (3/9) é informalmente o Dia do Obrigado no Japão.
🎬 Easter egg: Muito usado em animes idol como Love Live! e Idolm@ster.


🤝 4649 — よろしく (yoroshiku)

  • Significado: “Conto com você”, “Prazer”, “Seja legal comigo”

  • Leitura aproximada:

    • 4 = yo

    • 6 = ro

    • 4 = shi

    • 9 = ku

📱 Uso clássico:

  • Assinatura de mensagem

  • Apresentações

  • Fóruns e games online

💡 Dica Bellacosa: Yoroshiku não tem tradução direta. É quase um commit social.


😊 2525 — ニコニコ (niko-niko)

  • Significado: Sorriso, felicidade

  • Origem:

    • 2 = ni

    • 5 = ko

🎬 Easter egg master:

  • Nome do famoso site Niconico Douga, precursor dos vídeos comentados no Japão.


🐝 83 — はちみつ (hachimitsu)

  • Significado: Mel

  • Curiosidade: Usado em produtos, embalagens, nomes fofos

🍯 Cultura pop: Aparece em animes slice of life e doces.


😆 229 — にこにく (nikoniku)

  • Significado: Sorriso malicioso / sorriso travesso

  • Uso: Mangás, chats informais


⚠️ 893 — やくざ (yakuza)

  • Significado: Máfia japonesa

  • Origem histórica:

    • 8 (ya) + 9 (ku) + 3 (sa)
      → mão ruim no jogo hanafuda

🎬 Easter egg:

  • Aparece discretamente em placas, quartos de hotel inexistentes, números evitados.


💀 42 — しに (shini)

  • Significado: Morte

  • Motivo:

    • 4 = shi

    • 2 = ni

🏥 Curiosidade:

  • Quartos 42 e 49 são evitados em hospitais, igual ao nosso “13”.


🏠 110 — ひゃくとお (hyaku-tō)

  • Significado: Polícia
    🚑 119 — Ambulância / Bombeiros

📞 Sistema japonês, mas vira piada e referência em animes.


💖 831 — やさい (yasai)

  • Significado: Legumes

  • Uso: Campanhas de alimentação saudável


🎮 Onde isso aparece muito?

  • Animes e mangás

  • Games japoneses

  • Placas de carro

  • Datas comemorativas

  • Usernames

  • Nomes de personagens

💬 Comentário Bellacosa:
É como RACF, JCL e CICS — quem é de fora vê confusão. Quem é de dentro, lê tudo num piscar de olhos.


🧩 Conclusão — Números que falam

O goroawase mostra algo profundo da cultura japonesa:
👉 linguagem é contexto
👉 número é som
👉 som vira emoção

Enquanto no mainframe um código define o destino de um job, no Japão um número pode dizer “obrigado”, “te amo”, “conta comigo” ou “perigo”.

Da próxima vez que você vir um 39, não leia como inteiro.
Leia como sentimento.

39 por ler até aqui.