Translate

Mostrar mensagens com a etiqueta apf. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta apf. 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?

 

terça-feira, 15 de julho de 2025

Pontos de Função: um pouco sobre métricas. Parte I


Pontos de Função: um pouco sobre métricas. Parte I

Vagner Bellacosa
IBM Champion | Mainframe Evangelist & Educator | System Analyst – COBOL, PL/I, DB2, CICS

Métricas de Software: Vamos falar sobre pontos de função Parte I

Article content

Salve jovem padawan, após uma eletrizante noite com o Deploy da DIO, com tantas novidades neste Outubro de 2021, com surpresas a mil, agora teremos em nossa comunidade novos horizontes além mar, além dos projetos nacionais, chegaram os projetos internacionais em Portugal.

Article content

Agora nossa agenda conta com 163 cursos gratuitos em diversas tecnologias, para animar ainda mais novos bootcamps e acelerações é muita notícia fantástica, hoje meu trabalho esta próximo do limiar, este é o artigo 99° escrito com muito carinho, uma retribuição a nossa comunidade por tanta coisa recebida, da minha parte venho enriquecer um pouco mais nosso Gruppen com velhas historias de mainframe, preparados? Agora é hora de voltar ao laptop e bora terminar de escrever sobre Ponto de Função.


Article content

Pergunta do milhão

Responda como souber, é uma pergunta bem difícil e capciosa. Como podemos quantificar o trabalho e estimar o tempo para desenvolver um software? Se é pedido para codificar um aplicativo através da especificação em papel com fluxogramas/uml, quantas horas seriam necessárias para entregar o projeto com a chave na mão?

Article content

Antes de sair fazendo a moda do Dr. Ivon Saf: Estime o tempo necessário para ler os documentos de Analise Previa, Requisitos do Sistema e Especificações para codificar. Agora pense no tempo gasto com o pedidos de esclarecimento com analista senior? Com pessoal de infraestrutura? Com o pessoal da base de dados? Com o pessoal da rede? Com a auditoria? Com o pessoal da segurança dos dados e LGPD? Com os testes unitários? Testes de Integração? Testes de produção? Passagem do aplicativo entre os ambiente de desenvolvimento para aceite e após produção? Difícil ne? São muitas equipes envolvidas, muitas variáveis em jogo e para complicar fornecedores diferentes em cada etapa do processo.

Article content

Leia a posteriori: Síndrome do Dr. Ivon Saf, metendo os pés pelas mãos. https://web.digitalinnovation.one/articles/deu-ruim-no-levantamento-de-requisitos-a-sindrome-de-dr-ivon-saf

Article content

Na metodologia ágil tem aquele joguinho de poker para estimar, mas será que resolve para todas as atividades? Como proceder. O que fazer? Help. Calma, como sempre digo, nao entre em pânico.

Article content

Juntos vamos tentar esclarecer este tema terrível e aprender um pouco mais sobre métricas e pontos de função. Mas lembre-se cada empresa tem a sua própria calculadora e metodologia, alguns são segredos guardados a sete chaves, outros escancarados ao publico.

Article content

Introdução

Pontos de Função é uma palavra estranha e esquisita, os mais jovens talvez nunca tenham ouvido falar sobre ela, mas é uma técnica bem antiguinha, surgida la nos idos de 1979, mais uma vez nos laboratórios da IBM e publicado num artigo de Alian J. Albrecht intitulado Measuring Application Development Productivity, originalmente vocacionada para projetos em mainframe, mais precisamente nas linguagem Cobol, PL/I e Rexx, linguagens em paradigmas procedurais, mas que no decorrer dos anos, foi gradativamente expandindo-se para outras linguagens de programação em baixa plataforma.

Article content

PF é uma técnica de métrica de software, que é usada para estimar o esforço e o tempo gasto em uma determinada tarefa em Informática, sendo uma atividade retroalimentada em que resultados atuais, são avaliados, analisados e reinseridos no cálculo da métrica e aprimoradas para serem usada em projetos futuros, sendo dinâmica e fortemente usada para definir o melhor modelo de custos.

Article content

Sei que o tema é um pouco obscuro, relaxe, tentarei clarificar tudo antes do final, então para podermos prosseguir, vou definir alguns tópicos importantes, vou primeiro dar umas palavrinhas em teoria e na segunda parte deste artigo vamos de mão na massa, onde voltaremos ao tópico inicial elucidando o tema e aplicando a técnica, através de exemplos pratico: o calculo de PF de um desafio de código, usando uma planilha MS Excel para calcular, agora vamos as definições.

Article content

O que são métricas de software?

Programação é arte pura, nosso trabalho é muito artesanal, bem intelectual que dependente da habilidade pessoais de cada analista / programador, por isso os gestores de equipe, tentam através de testes, experimentos e muitas dores dor de cabeça , para determinar de maneira satisfatória o tempo gasto e o grau de dificuldade de uma tarefa, para cobrarem o valor Hora / Homem adequada e obterem boa margem de lucro ao venderem serviços de desenvolvimento em Fabricas de Software.

Article content

Não é uma atividade fácil devido a quantidade de variáveis entre elas o soft e hard skills do DEV, experiência em tecnologia, ambiente, empresa e disponibilidade para engajar-se no projeto. Nos últimos anos o desenvolvimento de software transformou-se numa Babel maluca com tanta especificações, arquiteturas e LPs.

Article content

E um tema bem delicado, que alguns grandes gestores erraram feio, caindo no erro crasso e clássico das 9 gravidas, que teoricamente dão a luz em um bebe na vã tentativa de salvar o prazo, pois o custo foi perdido faz tempo.

Article content

Trabalhar em desenvolvimento não é fácil

Imagine a quantidade de etapas que devemos percorrer e satisfazer ao programar, pois a codificação é uma atividade de ciências humanas em que lidar com pessoas dificulta muito, coloca vários impedimentos e travões. Seus soft skills são colocados a prova, treine lidar com pessoas, falar por email, telefone, chat e videoconferência. Controle seu emocional, muitas vezes no calor do momento, agimos irracionalmene e colocamos tudo a perder. Antes de falar pense, veja se é o melhor momento.

Article content

Estamos num adventure lutando contra ogros, orcs, goblins e dragões, para chegar ao castelo do mago e poder efetuar a guarda do programa em produção, uma tarefa digna de um mestre Jedi e cumprir prazos e custos nao é uma tarefa simples.

Article content
Atenha-se a inúmeras variáveis que estão em jogo, nao basta codificar, tem que fritar o peixe, olhar o gato, abanar a brasa e ir pra galera. Não é uma listagem exaustiva mas devemos nos ater nos seguintes temas:


  • Usabilidade
  • Técnicas
  • Segurança
  • Acessibilidade
  • Performance
  • Interoperabilidade

Article content

Usabilidade

Pense no usuário, pense na pessoa que ira utilizar o aplicativo. User-friendly é o que dizemos de um software fácil de operar, acessando menus, com telas de ajuda e na suas evoluções aprender suas novas funcionalidades rapidamente e nas mudanças de plataforma a curva de aprendizagem é mais célere, pensando em ajudar o usuário a utilizar o app sem erro. Um desafio e tanto ao desenvolvedor que deve atentar ao melhor caminho logico no preenchimento dos formulários e troca de dados entre o Sistema e o operador, usando tecnicas avançadas em UC e UI, pensar que quando comecei o problema eram as 24 linhas e 80 colunas de um BMS do CICS online.


Article content

Técnicas

A cada dia acadêmicos lançam novas formas de programar, os fabricantes e as comunidades lançam novas especificações, sejam em comandos novos, sejam em syntatic sugar para facilitar a codificação, releases e mais releases.


Deploys de linguagens de computação trazem sempre novos desafios, sejam em entendimento do código novo, seja na supressão ou evolução da linguagem, sem contar a mudança de paradigmas e tendências de manadas que enlouquecem qualquer dev com mais de 15 anos de experiência. é uma insanidade so.


Article content

Acessibilidade

Outra atenção é a dificuldade de codificar para tantos sistemas diferentes, hoje um usuário pode acessar o software através de computadores pessoais, laptops, tablets, smart phones e até tv. Gerando desafios no desenvolvimento de aplicativos.

Tantas necessidades devem ser atendidas, problemas com comunicação e falhas em transmissão de dados, causando gargalos no processamento e usuários que nao conseguem utilizar plenamente o aplicativo.

Article content

Performance

Ao codificar temos que ter código limpo, performático e de fácil entendimento para as equipes de sustentação, acesso ao banco de dados, comunicação entre servidores e atentos ao consumo de memória e CPU.

Cuidado ao codificar declarando variáveis em demasia, querys confusas ou com acesso desnecessários a tabelas, ícones e imagens grande demais para dispositions moveis.

Article content

Interoperabilidade

Palavra difícil e estranha, mais uma vez, não entre em pânico, o tiozão explica, trata-se da capacidade de um sistema informático dentro de uma infraestrutura especifica, poder se comunicar com outros sistemas e trocar arquivos em processamento de dados entre ambientes.

Article content

O que é Ponto de Função.

Viram quantas variáveis um dev tem que controlar para codificar, dificuldades não previstas que consomem tempo e por mais metodologias de controle surgem, é muita coisa para avaliar e atentar-se, imagine a tarefa hercúlea que é cobrar pelo serviço, nao me surpreende a terceirizaçao, quarteirizaçao e até quinteirizaçoes.

Article content

No passado a maioria dos analistas vinham de Engenharia Tradicionais e trouxeram técnicas para planejar, estimar, controlar e cronometrar o serviço, porém não obtiveram sucesso nesta tarefa, por isso foram criadas inúmeras metodologias, mas mesmo assim muitos softwares falharam redondamente nos prazos e custos de sua implementação.

Article content

Albrecht em seu artigo de 1979 elaborou um método em voga até hoje, em que um software era reduzido a menor parte possível e atribuía-se um ponto, no princípio o cálculo prendia-se a estimar o custo do software através das dificuldades em codifica-lo, era a quantidade de IFs, FOR, Selects, Evaluates e inúmeros outras iterações dentro da execução, acrescendo o acesso a base de dados com tipos de tabelas simples, com um , dois ou mais índices, uso de arquivos sequenciais para input e quantidades de outputs e listagens de impressora.

Article content

Fluxo detalhado.

O cálculo da função verifica o grau de complexidade, simplicidade de propósitos, consistência necessárias, vamos avaliar o tipo de contagem e o escopo da contagem, experiência da equipe e determinando bem as fronteiras da codificação, evitando abranger atividade de outros sistemas.

Não é uma tarefa fácil, pois dentro do ambiente de desenvolvimento temos diversos tipos de funções entre elas Função de Dados, Funções transacionais que indicam a dificuldade em desenvolvimento.

Article content

Apurando todas essas variáveis e seu peso relativo encontramos o Tamanho Funcional, cada instalação tem suas próprias especificidades, que implicam na facilidade de implementar a codificação, de posse deste dado podemos avaliar os caminhos críticos e o trabalho necessário.

Article content

Software legado em sustentação versus Migração versus Novas funcionalidades

Para aumentar o grau de dificuldade deste calculo para cada projeto existe uma especifidade única, que aumenta a quantidade de trabalho hora/homem, afinal acrescenta desafios e pontos em atenção, que um analista externo a instituição desconhece.

Um software legado em sustentação tem um grau maior de perigo, sua parada pode afetar outros sistemas dependentes ou modificar os outputs do processo devido há uma modificação não esperada ou planejada. Sendo atividades real-time, dificilmente podem ser estimadas com segurança. O custo de oportunidade é alto para softwares abendados, obrigando equipes a trabalharem madrugada adentro.

Article content

Uma migração de software de um ambiente para outro, tem muitos riscos o TBS Bank é uma prova desse risco, imagine toda a problemática de trocar a estrutura completa de um sistema, modificando base de dados, ambiente de execução e servidores, saindo de um ambiente conhecido rumo ao desconhecido.


Perfeitamente encaixada nas PFs, novas funcionalidades são talvez um dos cenários apresentados, que esta mais aderente a metodologia de PF, pois permite acrescentar funções sem afetar a logica principal e ser um trabalho pontual fácil de estimar..


Conclusão

Nesta primeira parte do artigo sobre pontos de função apenas apresentei alguns tópicos fundamentais, trilhando um caminho para transmitir o conhecimento e poder adentrar no tema sobre calculo de PF. Em verdade foi apresentado mais conceitos e riscos envolvidos na atividade.


Acredito que o jovem padawan tenha conhecido um pouco sobre a burocracia por trás da codificação, o trabalho administrativo para chegar ao custo estimado, que ao final será bem diferente do custo real. Onde um gestor devera comparar o valor orçado do valor real, apurado no momento da entrega.


Espero ter ajudado ate o próximo artigo.


Article content


Article content

Mais momento jabá, para distrair, conheça a locomotiva que pertenceu a Dom Pedro II e hoje esta em Indaiatuba trabalhando durante decadas na Cia Ithuana e Sorocabana, visite meu vídeo e veja para onde fui desta vez: https://www.youtube.com/watch?v=HUxWquSxBYc


Bom curso a todos.

Article content

https://www.linkedin.com/in/vagnerbellacosa/

Article content

https://github.com/VagnerBellacosa/


Pode me dar uma ajudinha no YouTube?

Article content

https://www.youtube.com/user/vagnerbellacosa