{"id":921994,"date":"2026-11-06T14:15:35","date_gmt":"2026-11-06T14:15:35","guid":{"rendered":"https:\/\/www.ninjaone.com\/blog\/politicas-de-seguranca-perfeitas\/"},"modified":"2026-11-06T14:15:35","modified_gmt":"2026-11-06T14:15:35","slug":"politicas-de-seguranca-perfeitas","status":"publish","type":"post","link":"https:\/\/www.ninjaone.com\/pt-br\/blog\/politicas-de-seguranca-perfeitas\/","title":{"rendered":"Por que n\u00e3o existem pol\u00edticas de seguran\u00e7a perfeitas"},"content":{"rendered":"

Pol\u00edticas de seguran\u00e7a perfeitas n\u00e3o existem \u2014 n\u00e3o porque sejam dif\u00edceis de escrever, mas porque refletem mal a realidade. H\u00e1 uma grande diferen\u00e7a entre uma pol\u00edtica escrita e uma pol\u00edtica escrita que d\u00e1 para aplicar<\/a>.<\/p>\n

A maioria das pol\u00edticas n\u00e3o foi feita para resistir ao cen\u00e1rio acelerado e em constante mudan\u00e7a em que vivemos. S\u00e3o pol\u00edticas escritas com boa inten\u00e7\u00e3o, mas que desmoronam porque foram pensadas para estados \u201cideais\u201d e cen\u00e1rios perfeitos.<\/p>\n

Por que pol\u00edticas boas falham na pr\u00e1tica<\/h2>\n

Quando eu era sysadmin e cuidava do gerenciamento de patches, ca\u00ed exatamente nessa armadilha. Tinha implementado o que parecia uma pol\u00edtica bem simples: todos os patches cr\u00edticos devem ser implantados em at\u00e9 30 dias ap\u00f3s o lan\u00e7amento. Era uma m\u00e9trica clara, f\u00e1cil de medir e, principalmente, atendia aos requisitos regulat\u00f3rios e de conformidade que precis\u00e1vamos cumprir.<\/p>\n

No papel, era \u00f3timo e exatamente o que boa seguran\u00e7a deveria ser. Ser\u00e1? Na pr\u00e1tica, desmoronou quase de imediato.<\/p>\n

Como eu tamb\u00e9m fazia parte do time respons\u00e1vel por acompanhar e instalar os patches em todos os endpoints e servidores, acabei consumindo sem perceber todo o meu tempo livre. Entre identificar o que precisava de patch e quando, testar dentro de TI (\u00e9ramos sempre as cobaias), agendar janelas de manuten\u00e7\u00e3o para o resto da organiza\u00e7\u00e3o e, enfim, implantar os patches, quase 30 dias j\u00e1 tinham passado. A\u00ed o ciclo recome\u00e7ava. E n\u00e3o sobrava tempo para nada al\u00e9m de ficar de bab\u00e1 dos patches.<\/p>\n

Para piorar, fizemos um teste de invas\u00e3o, e os achados do pentest eram bem diferentes dos nossos escaneamentos de vulnerabilidades<\/a>. Os pentesters insistiam para corrigirmos o que encontraram, mas parte disso n\u00e3o estava classificada como \u201cCr\u00edtica\u201d. Ent\u00e3o esses achados de alto risco s\u00f3 foram remediados bem depois dos cr\u00edticos.<\/p>\n

N\u00e3o foi uma falha de inten\u00e7\u00e3o. Querer patches em dia n\u00e3o era errado. A pol\u00edtica falhou porque n\u00e3o considerava o ambiente real, o risco verdadeiro para a organiza\u00e7\u00e3o nem as prioridades concorrentes. \u00c9 a\u00ed que a maioria das pol\u00edticas de seguran\u00e7a quebra. Elas s\u00e3o feitas para condi\u00e7\u00f5es perfeitas que n\u00e3o existem em ambientes de TI reais e, muitas vezes, n\u00e3o t\u00eam decis\u00f5es baseadas em risco. No fim, pol\u00edticas assim n\u00e3o s\u00e3o seguidas: s\u00e3o contornadas ou simplesmente ignoradas.<\/p>\n

E n\u00e3o s\u00e3o s\u00f3 as pol\u00edticas caseiras que caem nessa armadilha. At\u00e9 padr\u00f5es de mercado amplamente aceitos podem falhar quando aplicados sem entender as particularidades da sua organiza\u00e7\u00e3o e do seu ambiente.<\/p>\n

Quando o \u201cpadr\u00e3o de mercado\u201d deixa de ser \u00fatil<\/h2>\n

Os padr\u00f5es de mercado existem por bons motivos. Nascem de li\u00e7\u00f5es aprendidas com incidentes de seguran\u00e7a e viola\u00e7\u00f5es de dados e re\u00fanem a experi\u00eancia coletiva de profissionais de seguran\u00e7a. Eles d\u00e3o uma base que funciona para a maioria das organiza\u00e7\u00f5es na maior parte do tempo. O problema \u00e9 que \u201ca maioria das organiza\u00e7\u00f5es na maior parte do tempo\u201d ainda deixa muito espa\u00e7o para falhas.<\/p>\n

Um time de TI de uma ind\u00fastria aprendeu isso do jeito dif\u00edcil ao decidir refor\u00e7ar seus servidores Windows com os benchmarks CIS N\u00edvel 1. Os CIS Benchmarks s\u00e3o \u00f3timos pontos de partida. S\u00e3o respeitados, atualizados com frequ\u00eancia e recomendados por auditores e profissionais de seguran\u00e7a. Esse n\u00e3o era o problema.<\/p>\n

O problema foi achar que dava para aplic\u00e1-los de forma uniforme a todos os sistemas do ambiente. S\u00f3 que os sistemas de controle do ch\u00e3o de f\u00e1brica n\u00e3o s\u00e3o sistemas t\u00edpicos de usu\u00e1rio final. T\u00eam uma finalidade espec\u00edfica e requisitos espec\u00edficos, diferentes de \u00e1reas como contabilidade, por exemplo.<\/p>\n

Os benchmarks desativaram v\u00e1rios protocolos e servi\u00e7os legados dos quais os equipamentos industriais de 15 anos dependiam para se comunicar com o servidor. O resultado: produ\u00e7\u00e3o parada por boa parte do dia (6 horas) enquanto o time revertia as mudan\u00e7as \u00e0s pressas. O impacto financeiro n\u00e3o foi pequeno. N\u00e3o a ponto de quebrar a empresa, mas gerou bastante preocupa\u00e7\u00e3o e caos nos times de TI e de produ\u00e7\u00e3o.<\/p>\n

Aplicar os benchmarks CIS<\/a> n\u00e3o era a abordagem errada. Eles foram feitos para ambientes de TI modernos, com sistemas operacionais atuais e equipamentos atualizados. Mas s\u00e3o um ponto de partida, e nem toda configura\u00e7\u00e3o do benchmark \u00e9 ideal para um ambiente de tecnologia operacional, onde atualizar \u00e9 muito mais dif\u00edcil e a indisponibilidade pode causar impacto financeiro s\u00e9rio.<\/p>\n

\u00c9 aqui que seguir \u201cpadr\u00f5es de mercado\u201d \u00e0s cegas pode prejudicar. Esses benchmarks partem de premissas sobre o seu ambiente, seus recursos e suas opera\u00e7\u00f5es. Quando essas premissas n\u00e3o batem com a sua realidade \u2014 seja porque voc\u00ea roda sistemas legados, atua em um setor especializado ou lida com outras restri\u00e7\u00f5es que os benchmarks n\u00e3o preveem \u2014 seguir boas pr\u00e1ticas cegamente cria mais problemas do que resolve.<\/p>\n

Benchmarks s\u00e3o uma ferramenta \u00fatil e devem ser usados. Mas, com frequ\u00eancia demais, as pol\u00edticas exigem o uso desses benchmarks s\u00f3 para marcar uma caixinha de conformidade, sem antes entender os requisitos espec\u00edficos do ambiente.<\/p>\n

Como desenhar pol\u00edticas que funcionam no mundo real<\/h2>\n

Depois que minha pol\u00edtica original de 30 dias falhou, eu e meu time a redesenhamos em torno de resultados, n\u00e3o de prazos. A nova pol\u00edtica era focada em risco<\/a>. Havia v\u00e1rios adendos, mas este resume bem a ideia:<\/p>\n

\u201cVulnerabilidades cr\u00edticas que afetem ativos expostos \u00e0 internet com evid\u00eancia de explora\u00e7\u00e3o ativa devem ser mitigadas em at\u00e9 72 horas. Vulnerabilidades cr\u00edticas com c\u00f3digo de prova de conceito dispon\u00edvel devem receber patch em at\u00e9 7 dias. A mitiga\u00e7\u00e3o pode incluir patch, controles compensat\u00f3rios ou isolamento tempor\u00e1rio do servi\u00e7o. Todas as a\u00e7\u00f5es e exce\u00e7\u00f5es devem ser documentadas com aceita\u00e7\u00e3o de risco pelo CISO.\u201d<\/p>\n

A mudan\u00e7a real n\u00e3o foi s\u00f3 nos prazos. Passamos a priorizar vulnerabilidades e patches pela exposi\u00e7\u00e3o real: se os sistemas estavam expostos \u00e0 internet, se havia exploits circulando e quais dados esses sistemas tocavam.<\/p>\n

Mas, igualmente importante, entendemos que visibilidade \u00e9 essencial para TI. Implantamos escaneamento automatizado de vulnerabilidades<\/a> que alimentava diretamente nosso painel de gerenciamento de patches. Quando um sistema sa\u00eda da conformidade e ficava sem patches cr\u00edticos, sab\u00edamos na hora. Passamos a acompanhar m\u00e9tricas ao longo do tempo para ver o quanto est\u00e1vamos indo bem (ou n\u00e3o) e o que precisava melhorar.<\/p>\n

Tamb\u00e9m reconhecemos que, \u00e0s vezes, aplicar o patch dentro do prazo n\u00e3o era poss\u00edvel, por v\u00e1rios motivos. Nesses casos, precis\u00e1vamos de controles compensat\u00f3rios, de documenta\u00e7\u00e3o e de aprova\u00e7\u00e3o da lideran\u00e7a.<\/p>\n

No caso da pol\u00edtica dos CIS Benchmarks, a li\u00e7\u00e3o foi parecida, mas o time de TI chegou l\u00e1 por outro caminho. Eles n\u00e3o abandonaram os benchmarks nem os tiraram da pol\u00edtica. Em vez disso, atualizaram a pol\u00edtica para exigir avalia\u00e7\u00f5es de hardening CIS para cada tipo de sistema da organiza\u00e7\u00e3o, criando uma base do que quebraria ou n\u00e3o componentes de produ\u00e7\u00e3o. O time documentou quais benchmarks se aplicavam a cada tipo de sistema, quais conflitavam com os requisitos daquele tipo e quais controles compensat\u00f3rios foram usados. Os sistemas de produ\u00e7\u00e3o ganharam sua pr\u00f3pria base de hardening, os sistemas de usu\u00e1rio final ganharam a deles e os servidores tamb\u00e9m.<\/p>\n

Por onde seguir daqui<\/h2>\n

Como sabemos, quase nada em TI e seguran\u00e7a \u00e9 ideal. Inova\u00e7\u00e3o e avan\u00e7o tecnol\u00f3gico sempre v\u00e3o correr na frente da seguran\u00e7a.<\/p>\n

Nosso trabalho como profissionais de TI e seguran\u00e7a \u00e9 tirar o m\u00e1ximo do que temos em m\u00e3os, desenhando sistemas, processos e pol\u00edticas seguros o bastante para que usu\u00e1rios, departamentos e \u00e1reas do neg\u00f3cio operem com a maior seguran\u00e7a poss\u00edvel, sem travar demais essas opera\u00e7\u00f5es.<\/p>\n

Temos que aceitar que seguran\u00e7a perfeita n\u00e3o existe e entender que pol\u00edticas que exigem perfei\u00e7\u00e3o v\u00e3o falhar.<\/p>\n

Seguran\u00e7a funciona melhor quando faz parte do dia a dia da TI, e n\u00e3o quando \u00e9 acoplada depois. Funciona melhor quando \u00e9 a op\u00e7\u00e3o mais eficiente e mais pr\u00e1tica. Quando atrapalha o m\u00ednimo poss\u00edvel.<\/p>\n

Se o seu time precisar escolher entre entregar o trabalho e seguir uma pol\u00edtica de seguran\u00e7a, vai escolher entregar o trabalho todas as vezes. Desenhe suas pol\u00edticas para que essas duas coisas sejam a mesma escolha.<\/p>\n","protected":false},"excerpt":{"rendered":"

Pol\u00edticas de seguran\u00e7a perfeitas n\u00e3o existem \u2014 n\u00e3o porque sejam dif\u00edceis de escrever, mas porque refletem mal a realidade. H\u00e1 uma grande diferen\u00e7a entre uma pol\u00edtica escrita e uma pol\u00edtica escrita que d\u00e1 para aplicar. A maioria das pol\u00edticas n\u00e3o foi feita para resistir ao cen\u00e1rio acelerado e em constante mudan\u00e7a em que vivemos. S\u00e3o […]<\/p>\n","protected":false},"author":35,"featured_media":755711,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_relevanssi_hide_post":"","_relevanssi_hide_content":"","_relevanssi_pin_for_all":"","_relevanssi_pin_keywords":"","_relevanssi_unpin_keywords":"","_relevanssi_related_keywords":"","_relevanssi_related_include_ids":"","_relevanssi_related_exclude_ids":"","_relevanssi_related_no_append":"","_relevanssi_related_not_related":"","_relevanssi_related_posts":"","_relevanssi_noindex_reason":"","_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[12428],"tags":[],"class_list":["post-921994","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-seguranca"],"acf":[],"modified_by":null,"_links":{"self":[{"href":"https:\/\/www.ninjaone.com\/pt-br\/wp-json\/wp\/v2\/posts\/921994","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ninjaone.com\/pt-br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ninjaone.com\/pt-br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/pt-br\/wp-json\/wp\/v2\/users\/35"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/pt-br\/wp-json\/wp\/v2\/comments?post=921994"}],"version-history":[{"count":1,"href":"https:\/\/www.ninjaone.com\/pt-br\/wp-json\/wp\/v2\/posts\/921994\/revisions"}],"predecessor-version":[{"id":921995,"href":"https:\/\/www.ninjaone.com\/pt-br\/wp-json\/wp\/v2\/posts\/921994\/revisions\/921995"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/pt-br\/wp-json\/wp\/v2\/media\/755711"}],"wp:attachment":[{"href":"https:\/\/www.ninjaone.com\/pt-br\/wp-json\/wp\/v2\/media?parent=921994"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ninjaone.com\/pt-br\/wp-json\/wp\/v2\/categories?post=921994"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ninjaone.com\/pt-br\/wp-json\/wp\/v2\/tags?post=921994"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}