1

Boa! Gostei do post. Dá para ver como as profissões antigamente exigiam bem menos conhecimento dos profissionais. O webmaster não precisava saber nem metade do que um fullstack hoje em dia precisa saber.

Em termos de segurança, dá para ver como evoluiu muito. Naquela época, "segurança" era uma vergonha. Os sistemas eram tão inseguros que até adolescentes invadiam sistemas (literalmente, há vários casos históricos).

Muito disso foi por essa mentalidade da época que "segurança" era só mais um conhecimento do webmaster/desenvolvedor. Hoje, todos nós sabemos que essa percepção é absurdamente errada. Segurança hoje é uma área inteira com dezenas de subáreas e centenas de profissões.

É legal ver como segurança saiu de algo bobinho e fácil de aprender (naquela época) para algo que exige dedicação de muitos anos de estudos e especialização.

Acho incrível que em apenas 15~20 anos segurança tenha mudado tanto e se tornado algo completamente diferente do que era nessa época. Se é que nos anos ~2000 dava mesmo pra ser chamado de "segurança", de tão bobinho que era. 😂

Carregando publicação patrocinada...
2

Meus 2 cents extendidos,

Seu comentario foi certeiro - e evoca uma frase de 400 anos mas atual como nunca: "Se vi mais longe, foi por estar sobre os ombros de gigantes" de Isaac Newton.

O Webmaster de 1998 ou o desenvolvedor dos anos 2000 nao sabiam "menos" do que um Fullstack de hoje; eles sabiam coisas diferentes sobre uma infraestrutura que ainda estava sendo inventada.

Pense comigo:

Hoje, um desenvolvedor joga uma linha de comando e da deploy em uma infraestrutura global na AWS ou Vercel.

Em 1998, precisavamos baixar o codigo-fonte do servidor Apache via FTP, compilar o binario no braco, configurar o arquivo httpd.conf linha por linha, entender de mascara de sub-rede e diversos outros detalhes.

Sobre a seguranca ser "bobinha" ou "uma vergonha" na epoca, a verdade eh que estavamos descobrindo as vulnerabilidades que hoje sao a base de livros para formacao e estudo. Os ataques eram feitos por adolescentes justamente porque ninguem sabia o que era um ataque. Conceitos basicos como SQL Injection, Buffer Overflow ou Cross-Site Scripting (XSS) estavam sendo catalogados e mitigados pela primeira vez, conforme iam surgindo.

A seguranca nao mudou porque "virou uma area seria", ela se ramificou em centenas de especializacoes porque o ecossistema escalou de forma brutal. Hoje temos o luxo de ter profissionais focados exclusivamente em AppSec, Pentest ou DevSecOps porque aquela epoca gerou cicatrizes suficientes para mostrar onde estavam os buracos.

Mas eh este o fluxo do crescimento do conhecimento - geracao apos geracao, aprendendo com os erros e acertos dos que vieram antes construindo a infra atual onde seus novos expoentes tambem cometem erros e acertos, preparando novas geracoes. Ou parafraseando o Dr. Manhattan: "Nada termina, Nada nunca termina."

Provavelmente nunca vai existir um "framework final", uma "arquitetura perfeita" ou um estado onde a seguranca da informacao estara 100% resolvida e estatica.

A tecnologia eh um ciclo infinito de caos, ordem, abstracao e novo caos. E que bom que eh assim... senao a gente nao teria emprego e nem assunto para debater aqui no TabNews !

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

1

Hoje, um desenvolvedor joga uma linha de comando e da deploy em uma infraestrutura global na AWS ou Vercel.

Em 1998, precisavamos baixar o codigo-fonte do servidor Apache via FTP, compilar o binario no braco, configurar o arquivo httpd.conf linha por linha, entender de mascara de sub-rede e diversos outros detalhes.

Acho que para quem usa soluções como Vercel, Heroku etc. você tem razão. Mas a realidade hoje em dia não é bem assim para quem configura infra séria em uma AWS da vida ao invés dessas soluções simplificadas.

Eu mesmo estou acostumado a fazer coisas bem mais complexas do que isso que você descreveu de 1998. Já configurei Apache linha por linha e posso dizer o mesmo do nginx. Já configurei firewall, redes e subredes, VPN, banco de dados, docker, mensageria, Ansible e um monte de outras coisas. Tudo isso quando eu trabalhava como fullstack.

Hoje em dia a infra é bem complexa, por isso mesmo existem soluções como Heroku e Vercel: para pessoas que não dão conta de configurar infra em uma AWS da vida.

Sistemas sérios não usam Heroku/Vercel porque encarece muito o custo da infra. Só dev independente que não entende de DevOps usa esse tipo de coisa.

E eu posso nunca ter compilado o Apache na minha vida, mas estou acostumado a compilar projetos bem mais complexos, como o kernel Linux por exemplo.

Provavelmente nunca vai existir um "framework final", uma "arquitetura perfeita" ou um estado onde a seguranca da informacao estara 100% resolvida e estatica.

Concordo. Mas é importante entender que segurança de verdade não é sobre aprender a usar ferramentas ou frameworks, mas sim sobre fundamentos de computação e mentalidade.

Inclusive a gente tem até o termo pejorativo script kiddie (skid) que é para se referir justamente a caras que aprendem a usar ferramentas e acham que são "hackers" por causa disso.

Segurança de verdade não é feita configurando e/ou rodando ferramentas. Quem faz isso não é "hacker", é script kiddie.

1

Meus 2 cents extendidos,

Sim, tem pontos que separam o desenvolvimento por hobby da engenharia de software em escala corporativa.

No uso de plataformas como Heroku ou Vercel, o debate sobre custo-beneficio eh excelente: para grandes corporacoes, o custo de saida (egress) e o preco por recurso nessas plataformas costuma inviabilizar a operacao.

Me parece, no entanto, que o mercado comecou a ver valor nelas nao apenas por "incompetencia" dos devs, mas tambem pelo foco no "Time to Market" - muitas empresas preferem pagar 5x mais caro na infraestrutura inicial da Vercel para ter validacao de produto em semanas, delegando a complexidade da infra, e depois fazer a migracao para instancias puras na AWS/Azure/whatever quando ganham tracao: eh uma troca de dinheiro por velocidade de engenharia de entrega.

Sobre seguranca e os script kiddies, voce foi no cerne da questao: seguranca eh mentalidade e fundamento, não ferramenta.

Rodar um scanner de vulnerabilidades automatico ou configurar um WAF por um tutorial nao torna ninguém um profissional de seguranca - seguir um passo-a-passo ou walkthrough no Kali nao qualifica, apesar de ser um comeco.

Quem nao entende o que acontece a nivel de sistema operacional, gerenciamento de memoria e protocolos de rede esta apenas replicando receitas de bolo, e sem os fundamentos de computacao (aqueles que voce exercita ao compilar um kernel Linux, por exemplo, o basico do basico de quem esta comecando neste seara e que muitos acabam ignorando e pulando a etapa), o profissional fica refem da ferramenta. Se a ferramenta muda ou falha, ele perde o chao.

Mas eh isso - por mais profissionais que se qualifiquem, de facto e de direito, para enfrentar os desafios que se acumulam no dia-a-dia.

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

1

[...] e sem os fundamentos de computacao (aqueles que voce exercita ao compilar um kernel Linux, por exemplo, o basico do basico de quem esta comecando neste seara e que muitos acabam ignorando e pulando a etapa)

Com todo respeito, mas discordo totalmente do que foi afirmado aqui. Eu entendo que compilar o kernel possa ser mais complicadinho para um desenvolvedor web, mas eu discordo totalmente que você exercita algum fundamento de computação compilando o kernel.

Eu não diria nem que é o "básico do básico", eu diria que está pelo menos uns 20 níveis abaixo disso. A única coisa que você aprende compilando o kernel são configurações do kernel e a usar Makefiles. Nada disso é fundamento de computação.

Fundamentos de computação de verdade são completamente diferentes disso e ordens de grandeza mais complexo.

1