{"id":3502,"date":"2021-11-14T12:03:14","date_gmt":"2021-11-14T15:03:14","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=3502"},"modified":"2024-01-11T17:58:22","modified_gmt":"2024-01-11T20:58:22","slug":"fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/","title":{"rendered":"Fundamentos para a arquitetura de sistemas seguros \/ Cap\u00edtulo 10 v 1.1"},"content":{"rendered":"Dentre todos os atributos de qualidade arquiteturais, seguran\u00e7a \u00e9 o que vem ganhando mais destaques nos \u00faltimos anos. Ainda mais do que escalabilidade e performance!\n
\n

Fen\u00f4menos com impacto mundial, como a pandemia de COVID-19, aceleraram a ado\u00e7\u00e3o de recursos e ferramentas digitais, bem como a frequ\u00eancia e a gravidade de incidentes. Legisla\u00e7\u00f5es ainda imaturas est\u00e3o entrando em vigor e a incerteza sobre o que \u00e9 obrigat\u00f3rio ou simplesmente respons\u00e1vel \u00e9 parte do cotidiano.<\/p>\n

No passado, era comum que apenas empresas que trabalhassem com dados obviamente sens\u00edveis se preocupassem com seguran\u00e7a. Hoje, essa distin\u00e7\u00e3o n\u00e3o \u00e9 mais aplic\u00e1vel.<\/p>\n

H\u00e1 uma certa tend\u00eancia de dar \u00eanfase, na pr\u00e1tica arquitetural, a padr\u00f5es e estilos. Entretanto, essa abordagem nem sempre \u00e9 a melhor. A defini\u00e7\u00e3o de restri\u00e7\u00f5es e atributos de qualidade, observando os objetivos de neg\u00f3cio, \u00e9 premissa para um trabalho bem-feito. Seguran\u00e7a \u00e9 importante demais para ser um tema secund\u00e1rio.<\/strong><\/p>\n

Motiva\u00e7\u00f5es para “pensar seguran\u00e7a”<\/h2>\n

Compet\u00eancia tecnol\u00f3gica \u00e9 fundamento para o sucesso nos neg\u00f3cios.<\/strong> Cadeias produtivas est\u00e3o cada vez mais integradas. No\u00a0“ch\u00e3o de f\u00e1brica”, as m\u00e1quinas f\u00edsicas j\u00e1 t\u00eam “g\u00eameas digitais”. No varejo, as vendas s\u00e3o apoiadas por tecnologia e ocorrem em multicanalidade, com curadoria individual.<\/p>\n

Fora das empresas, a tecnologia vem impactando, de maneira evidente, cada vez mais, o dia-a-dia das pessoas.<\/strong>\u00a0<\/strong>Bens de consumo\u00a0t\u00eam cada vez mais sensores, processadores e conex\u00f5es com a internet. Produtos tecnol\u00f3gicos s\u00e3o canais por onde consumimos servi\u00e7os, muitos deles essenciais.<\/p>\nA onipresen\u00e7a de sistemas digitais, tanto na ind\u00fastria quanto nas rotinas individuais, al\u00e9m de aumentar o impacto percebido de falhas acidentais, os tornam alvos naturais para ataques criminosos. Por isso, seguran\u00e7a \u00e9 atributo de qualidade cada vez mais importante em arquiteturas modernas. <\/strong>Sistemas inseguros amea\u00e7am empresas, tanto sob aspectos diretamente financeiros e de imagem, e, n\u00e3o raro, a vida das pessoas!\n

\n

Infelizmente, sistemas dificilmente ser\u00e3o seguros acidentalmente, ou seja, sem projeto apropriado. O acaso, quando se trata de seguran\u00e7a em sistemas, \u00e9 desfavor\u00e1vel e n\u00e3o d\u00e1 prote\u00e7\u00e3o aos distra\u00eddos.\u00a0<\/strong><\/p>\n

Seguran\u00e7a \u00e9 um processo!<\/h2>\n

Problemas de seguran\u00e7a t\u00eam origem na maldade, inoc\u00eancia, estupidez ou infort\u00fanio humano.\u00a0<\/strong>As medidas para tornar sistemas mais seguros incluem mecanismos para coibi\u00e7\u00e3o de a\u00e7\u00f5es maliciosas, preven\u00e7\u00e3o de uso inadequado ou descuidado e, finalmente, planos de conting\u00eancia.<\/p>\nSeguran\u00e7a n\u00e3o “acontece”, tampouco \u00e9 “ligada” em sistemas. Na pr\u00e1tica, ela \u00e9 garantida por projeto cuidadoso, implementa\u00e7\u00e3o precisa, manuten\u00e7\u00e3o disciplinada e opera\u00e7\u00e3o monitorada.\n

\n
\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

Seguran\u00e7a \u00e9 um processo.<\/em><\/p>\n

\r\n

Bruce Schneier<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

\r\n

World Trade Center<\/p>\r\n<\/p>\n

H\u00e1 dezenas de relatos de empresas que mantinham sistemas principais e suas redund\u00e2ncias distribu\u00eddas nas duas torres do World Trade Center<\/em>, tragicamente atacadas em 11 de setembro de 2001. Essa estrat\u00e9gia, aparentemente l\u00f3gica em primeira an\u00e1lise, se mostrou catastroficamente equivocada.<\/p>\n

Imprud\u00eancia ou infort\u00fanio?<\/p>\n

<\/div>\n

Sistemas\u00a0desenvolvidos e mantidos com processos que n\u00e3o d\u00e3o \u00eanfase para a seguran\u00e7a t\u00eam alta probabilidade de serem “vitimados” direta ou indiretamente<\/strong>.<\/p>\n

Seguran\u00e7a bem implementada desencoraja e co\u00edbe condutas maliciosas, previne enganos e protege contra infort\u00fanios (afinal, acidentes acontecem). Por isso, diminui desperd\u00edcios de tempo e dinheiro, protegendo a privacidade das pessoas e a reputa\u00e7\u00e3o das marcas.<\/p>\n

Seguran\u00e7a \u00e9 CIA<\/h2>\n

S\u00e3o atributos de qualidade associados com seguran\u00e7a a confidencialidade, integridade e disponibilidade (availability<\/em>).<\/p>\n

A confidencialidade<\/u> tem rela\u00e7\u00e3o com a garantia de que o acesso a leitura e modifica\u00e7\u00e3o de informa\u00e7\u00f5es ser\u00e1 restrito a aqueles que possuem autoriza\u00e7\u00e3o.<\/p>\n

A integridade<\/u>, por sua vez, indica que apenas dados v\u00e1lidos s\u00e3o aceitos.<\/p>\n

Finalmente, disponibilidade<\/u> garante que dados permanecer\u00e3o dispon\u00edveis quando necess\u00e1rios, frente a conduta maliciosa, inoc\u00eancia ou est\u00fapida dos usu\u00e1rios.<\/p>\n

Seguran\u00e7a \u00e9 um “concern<\/i>” arquitetural<\/h2>\n

Boas pr\u00e1ticas de arquitetura de software visam contribuir para o atendimento dos objetivos de neg\u00f3cio, respeitando restri\u00e7\u00f5es, atingindo atributos de qualidade.<\/p>\n

A seguran\u00e7a \u00e9, sob o ponto de vista da arquitetura de software, um atributo de qualidade.<\/strong> Como tal, precisa ser adequadamente descrito e priorizado de acordo com os poss\u00edveis impactos para o atendimento dos objetivos de neg\u00f3cio.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Seguran\u00e7a \u00e9 como uma corrente, onde a for\u00e7a \u00e9 determinada pelo elo mais fraco.<\/em>\r\n

Bruce Schneier<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nA prioriza\u00e7\u00e3o da seguran\u00e7a durante o processo de design <\/em>arquitetural\u00a0determina a natureza e a severidade das restri\u00e7\u00f5es arquiteturais derivadas. Por sua vez, essas restri\u00e7\u00f5es ir\u00e3o governar o projeto de componentes e suas propriedades, como responsabilidades e relacionamentos, bem como a estrat\u00e9gia evolutiva.\n

\r\n

Restri\u00e7\u00f5es como ativo arquitetural<\/p>\r\n<\/p>\n

Roy Fielding, em sua tese de douturado que formalizou REST, sinaliza a import\u00e2ncia da defini\u00e7\u00e3o de restri\u00e7\u00f5es como pr\u00e1tica arquitetural. Afinal, REST \u00e9 WWW com restri\u00e7\u00f5es.<\/p>\n

O exerc\u00edcio maduro da arquitetura de software \u00e9 caracterizado pela defini\u00e7\u00e3o assertiva de restri\u00e7\u00f5es, antes de qualquer projeto propositivo, como forma pr\u00e1tica de validar as solu\u00e7\u00f5es propostas.<\/div>\n

Seguran\u00e7a \u00e9 um atributo de qualidade “invis\u00edvel”<\/h2>\nOs custos relacionados com seguran\u00e7a t\u00eam rela\u00e7\u00e3o com a preven\u00e7\u00e3o de perdas e n\u00e3o com a gera\u00e7\u00e3o de ganhos. Por isso, embora necess\u00e1rios s\u00e3o sempre questionados. <\/strong>Seguran\u00e7a \u00e9 um atributo “invis\u00edvel”, ou seja, s\u00f3 percebido quando h\u00e1 problemas.\n
\n

Importante destacar que o\u00a0Brasil, hoje, \u00e9 segundo colocado mundial na rela\u00e7\u00e3o de pa\u00edses com maior volume de ataques cibern\u00e9ticos identificados<\/strong>. Logo, os riscos associados a opera\u00e7\u00f5es tecnol\u00f3gicas em nosso pa\u00eds s\u00e3o inerentemente mais altos.<\/p>\nCabe aos arquitetos a responsabilidade de evidenciar os benef\u00edcios de priorizar a seguran\u00e7a. Para isso, \u00e9 \u00fatil estimar os custos poss\u00edveis na ocorr\u00eancia “eventos ruins”. \n

\n

Seguran\u00e7a pode “conflitar” com a confiabilidade<\/h2>\n

As decis\u00f5es arquiteturais relacionadas a seguran\u00e7a tratam de riscos diferentes daqueles relacionados a confiabilidade. Embora os temas aparentem similaridade, na pr\u00e1tica, s\u00e3o bem distantes.<\/p>\n

Riscos relacionados a confiabilidade s\u00e3o, por natureza, relativos a infort\u00fanios, a ingenuidade ou incompet\u00eancia humana, mas n\u00e3o \u00e0 maldade.<\/strong> S\u00e3o riscos para a confiabilidade, por exemplo, falhas na atualiza\u00e7\u00e3o de componentes ou no hardware. Riscos de seguran\u00e7a, por outro lado, geralmente decorrem da exist\u00eancia de “advers\u00e1rios” atuando, de forma ativa ou passiva, para explorar vulnerabilidades.<\/strong><\/p>\n

Decis\u00f5es de design\u00a0<\/em>relacionadas a confiabilidade devem assumir que alguma coisa pode “dar errado” em algum momento. J\u00e1 as decis\u00f5es relacionadas \u00e0 seguran\u00e7a devem assumir que h\u00e1, sempre, algo ou algu\u00e9m tentando “fazer as coisas darem errado”.<\/p>\nDecis\u00f5es relacionadas a confiabilidade frequentemente implicam na adi\u00e7\u00e3o de redund\u00e2ncia aos sistemas. Entretanto, enquanto a redund\u00e2ncia \u00e9 uma coisa boa para quando algo “d\u00e1 errado” ela amplia a superf\u00edcie de ataque para quem est\u00e1 tentando “fazer as coisas darem errado”.\n

\n

A recupera\u00e7\u00e3o de incidentes relacionados a confiabilidade geralmente envolvem v\u00e1rias mais pessoas, com mais “pontos de vista”, atuando para identificar e mitigar causas raiz. Em contraste, incidentes relacionados com seguran\u00e7a geralmente t\u00eam poucos envolvidos e somente compartilham informa\u00e7\u00f5es que realmente precisem ser compartilhadas.<\/p>\n

N\u00e3o raro, informa\u00e7\u00f5es em logs\u00a0<\/em>que cooperam para resolu\u00e7\u00e3o mais r\u00e1pida de sistemas em produ\u00e7\u00e3o tamb\u00e9m s\u00e3o valiosas para agentes mal-intencionados que, ali\u00e1s, precisam de apenas “um caminho aberto”.<\/strong><\/p>\n

Seguran\u00e7a pode “convergir” com confiabilidade<\/h2>\n

Tanto seguran\u00e7a quanto confiabilidade s\u00e3o atributos de qualidade emergentes, ou seja, resultantes de decis\u00f5es de design.<\/em><\/p>\nSistemas confi\u00e1veis e seguros geralmente emergem de um design<\/em> cuidadoso, atento a ambos atributos, desde o in\u00edcio. Para n\u00e3o serem “v\u00edtimas” de eros\u00e3o arquitetural, sistemas precisam ser testados constantemente, preferencialmente, atrav\u00e9s de\u00a0Fitness Functions.<\/em>\n

\n

Em sistemas mais complexos, os maiores desafios, tanto para a confiabilidade como para seguran\u00e7a, decorrem da intera\u00e7\u00e3o entre os componentes. Manter sistemas simples colabora para ambos atributos, indiretamente, colaborando para o MTTR.<\/p>\n

\r\n

MTTR ou MTBF? Depende! Mas sempre com MTTD<\/p>\r\n<\/p>\n

Muitos times de engenharia priorizam aumentar o MTBF (tempo m\u00e9dio entre falhas) no lugar de reduzir o MTTR (tempo m\u00e9dio para se recuperar de falhas).<\/p>\n

A escolha pelo MTBF acaba justificando\u00a0deploys\u00a0<\/em>menos frequentes (ningu\u00e9m quer mexer em um sistema que est\u00e1 funcionando), logo, pacotes de atualiza\u00e7\u00e3o maiores, o que causa mais dificuldade para detectar problemas, gerando mais\u00a0rollbacks\u00a0<\/em>e aumentando o leadtime<\/em>.<\/p>\n

MTTR, por outro lado, \u00e9 incentivo para pacotes de atualiza\u00e7\u00e3o menores, gerados por\u00a0deploys <\/em>mais frequentes, teoricamente com impactos menores, menos\u00a0rollbacks<\/em>, minimizando o\u00a0leadtime.<\/em><\/p>\n

MTTR ou MTBF? Depende muito das implica\u00e7\u00f5es para seguran\u00e7a. Entretanto, independente da op\u00e7\u00e3o, \u00e9 importante observar uma tercerira m\u00e9trica: MTTD (tempo m\u00e9dio para detec\u00e7\u00e3o de falhas).<\/p>\n

O MTTD refere-se ao tempo m\u00e9dio necess\u00e1rio para descobrir (ou perceber) um poss\u00edvel<\/del> incidente. Em termpos pr\u00e1ticos,\u00a0 a quantidade de tempo que o time do SOC ou Seguran\u00e7a da Informa\u00e7\u00e3o precisou para reconhecer uma ocorr\u00eancia.<\/p>\n

<\/div>\n

Seguran\u00e7a implica combina\u00e7\u00e3o de software, infraestrutura e opera\u00e7\u00f5es<\/h2>\nO atendimento da seguran\u00e7a, como atributo de qualidade, demanda coopera\u00e7\u00e3o dos times respons\u00e1veis por: 1) projeto, implanta\u00e7\u00e3o e manuten\u00e7\u00e3o de software; 2) projeto, deploy\u00a0<\/em>e manuten\u00e7\u00e3o de infraestrutura; e 3) sustenta\u00e7\u00e3o das opera\u00e7\u00f5es. Por isso, especialistas em infraestrutura e opera\u00e7\u00f5es s\u00e3o mais que bem-vindos nas discuss\u00f5es arquiteturais dedicadas a seguran\u00e7a, sobretudo para revis\u00e3o do conjunto de restri\u00e7\u00f5es desenvolvidos.\n
\n

Recomenda\u00e7\u00f5es b\u00e1sicas para mitiga\u00e7\u00e3o de riscos de seguran\u00e7a<\/h2>\n

Projetar sistemas seguros \u00e9 tarefa dif\u00edcil.<\/strong> Quanto maiores os riscos associados, tamb\u00e9m maiores s\u00e3o as demandas de envolver especialistas de maneira ativa em todo o ciclo de vida da solu\u00e7\u00e3o. Entretanto, h\u00e1 algumas estrat\u00e9gias b\u00e1sicas que podem e devem ser observadas sempre nas atividades relacionadas \u00e0 arquitetura, pelos arquitetos.<\/p>\n

\n

Reduzir “privil\u00e9gios” ao m\u00ednimo poss\u00edvel<\/h4>\nRiscos de seguran\u00e7a s\u00e3o consideravelmente mitigados quando o projeto de intera\u00e7\u00e3o do software restringe privil\u00e9gios ao m\u00ednimo necess\u00e1rio, solicitando “eleva\u00e7\u00e3o de autoridade” para opera\u00e7\u00f5es com impactos mais altos. Medidas assim, previnem problemas provenientes de descuidos, como, por exemplo, usu\u00e1rios que “esquecem” sistemas logados merc\u00ea de agentes mal-intencionados.\n
\n

Seguindo a mesma linha de racioc\u00ednio, processos “rodando” sistemas devem “usu\u00e1rios pr\u00f3prios” com privil\u00e9gios junto ao ambiente operacional reduzidos para o essencial. No caso de intermedia\u00e7\u00e3o com sistemas externos, deve-se considerar a ado\u00e7\u00e3o de redes DMZ<\/p>\n

\r\n

DMZ<\/p>\r\n<\/p>\n

DMZ ou zona desmilitarizada, \u00e9 uma sub-rede que cont\u00e9m e exp\u00f5e servi\u00e7os de uma organiza\u00e7\u00e3o para uma rede maior e n\u00e3o confi\u00e1vel, geralmente a Internet.<\/p>\n

As regras de seguran\u00e7a relacionadas a redes DMZ s\u00e3o:<\/p>\n

    \n
  • A rede interna pode iniciar conex\u00f5es a qualquer uma das outras redes, mas nenhuma das outras redes pode iniciar conex\u00f5es nesta.<\/li>\n
  • A rede p\u00fablica (internet) n\u00e3o pode iniciar conex\u00f5es na rede interna, mas pode na DMZ.<\/li>\n
  • A DMZ n\u00e3o pode fazer conex\u00f5es \u00e0 rede interna, mas pode na rede p\u00fablica.<\/li>\n<\/ul>\n

    <\/div>\n

    Decompor sistemas em “contextos delimitados” (de seguran\u00e7a)<\/h4>\nA decomposi\u00e7\u00e3o de sistemas em componentes aut\u00f4nomos, al\u00e9m de facilitar o evolvability<\/em> e a estrutura\u00e7\u00e3o de times, \u00e9 excelente estrat\u00e9gia para desenvolvimento de sistemas seguros.\n
    \n

    Componentes independentes devem ter acesso apenas a recursos sens\u00edveis relacionados \u00e0s responsabilidades que cumprem. M\u00f3dulos fiscais (e seus usu\u00e1rios), por exemplo, n\u00e3o devem ter acesso aos recursos utilizados por m\u00f3dulos de venda e vice-versa.<\/p>\n

    Estabelecer rela\u00e7\u00f5es de confian\u00e7a (entre componentes)<\/h4>\n

    Idealmente, a intera\u00e7\u00e3o entre componentes deve ser planejada. Quanto maior o acoplamento aferente de um componente, maiores s\u00e3o riscos potenciais que deste componente para a seguran\u00e7a.<\/p>\n

    Sempre que poss\u00edvel, a restri\u00e7\u00e3o de acessos de fontes n\u00e3o planejadas deve ser garantida em infraestrutura, adotando certificados ou outros mecanismos de identifica\u00e7\u00e3o.<\/p>\n

    Monitorar sistemas consistentemente<\/h4>\n

    Todos os eventos sens\u00edveis relacionados a seguran\u00e7a devem ser monitorados e logados em bases n\u00e3o viol\u00e1veis.<\/p>\n

    Em cen\u00e1rios onde seguran\u00e7a for realmente prioridade, todas as altera\u00e7\u00f5es em “entidades” cr\u00edticas devem ser armazenadas e gerenciadas em bases de dados\u00a0append-only .<\/em><\/p>\n

    Adotar pr\u00e1ticas defensivas em diversos n\u00edveis de “profundidade”<\/h4>\n

    Componentes com criticidade para a seguran\u00e7a n\u00e3o devem “confiar” em verifica\u00e7\u00f5es pr\u00e9vias, Por isso, implementam e avaliam solicita\u00e7\u00f5es de outros componentes seguindo alguma forma de controle de acesso.<\/p>\n

    Projetar seguran\u00e7a como se “ofensores” pudessem “ler o manual”<\/h4>\n
    \n
    \n
    \n
    \n

    N\u00e3o projete sistemas de seguran\u00e7a assumindo que seus “segredos” est\u00e3o seguros. Eventualmente, dados e estrat\u00e9gias preservados de maneira ing\u00eanua se tornam p\u00fablicos.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

    N\u00e3o “reinventar a roda”<\/h4>\n

    Quase nunca \u00e9 boa id\u00e9ia criar tecnologia de seguran\u00e7a dentro de casa. N\u00e3o implemente seu mecanismo de criptografia, mecanismos de identidade, tecnologia de persist\u00eancia inviol\u00e1vel, etc. Tenha humildade!<\/p>\n

    Tecnologias e protocolos consagrados eventualmente s\u00e3o dif\u00edceis de aprender e adotar, mas esta caracter\u00edstica n\u00e3o \u00e9 indevida. N\u00e3o cometa o erro de querer simplificar as coisas “reinventando a roda”.<\/p>\n

    STRIDE<\/h2>\n

    Modelagem de amea\u00e7as (threats modeling<\/em>) \u00e9 tema amplo que demanda abordagem profissional especialista. Entretanto, \u00e9 \u00fatil para arquitetos, sobretudo em projetos intensivos em seguran\u00e7a, conhecer, pelo menos alguma terminologia. A Microsoft, por exemplo, utiliza o modelo STRIDE para categorizar diferentes tipos de amea\u00e7as e simplificar discuss\u00f5es a respeito de seguran\u00e7a.<\/p>\n

    STRIDE \u00e9 acr\u00f4nimo para\u00a0Spoofing,\u00a0<\/em>Tampering, Repudiation, Information Disclosure, Denial of Service\u00a0<\/em>e\u00a0Elevation of Previlege.\u00a0<\/em>Onde:<\/p>\n

      \n
    • S<\/strong>poofing<\/em> \u00e9 sobre acessar ilegalmente e, em seguida, usar as informa\u00e7\u00f5es de autentica\u00e7\u00e3o de usu\u00e1rios, como nome de usu\u00e1rio e senha;<\/li>\n
    • T<\/strong>ampering<\/em> envolve a modifica\u00e7\u00e3o maliciosa de dados. Os exemplos incluem altera\u00e7\u00f5es n\u00e3o autorizadas feitas em dados persistentes, como os mantidos em um banco de dados, e a altera\u00e7\u00e3o dos dados \u00e0 medida que fluem entre dois computadores em uma rede aberta, como a Internet;<\/li>\n
    • R<\/strong>epudiation <\/em>acontece quando usu\u00e1rios que negam a realiza\u00e7\u00e3o de uma a\u00e7\u00e3o sem que outras partes tenham como provar o contr\u00e1rio. N\u00e3o-rep\u00fadio refere-se \u00e0 capacidade de um sistema de conter amea\u00e7as de rep\u00fadio;<\/li>\n
    • I<\/strong>nformation Disclosure\u00a0<\/em>\u00e9 sobre exposi\u00e7\u00e3o inadequada de dados;<\/li>\n
    • D<\/strong>enial of Access <\/em>trata de ataques de agentes mal-intecionados que impedem acesso de usu\u00e1rios v\u00e1lidos – por exemplo, tornando um servidor indispon\u00edvel;<\/li>\n
    • E<\/strong>levation of Previlege <\/em>quando um usu\u00e1rio sem privil\u00e9gios obt\u00e9m acesso privilegiado e, portanto, tem acesso suficiente para comprometer ou destruir todo o sistema.<\/li>\n<\/ul>\n

      Riscos mais frequentes para seguran\u00e7a (segundo OWASP)<\/h2>\n

      Open Web Application Security Project<\/em> (OWASP) \u00e9 uma funda\u00e7\u00e3o sem fins lucrativos, iniciada em 2001, que objetiva melhorar a qualidade da seguran\u00e7a em sistemas de software.\u00a0Trata-se de uma comunidade aberta dedicada a capacitar organiza\u00e7\u00f5es na concep\u00e7\u00e3o, desenvolvimento, aquisi\u00e7\u00e3o, opera\u00e7\u00e3o e manuten\u00e7\u00e3o de aplica\u00e7\u00f5es confi\u00e1veis. Sem d\u00favidas, \u00e9 ativo de conhecimento para qualquer arquiteto.<\/p>\n

      H\u00e1 anos, a organiza\u00e7\u00e3o mant\u00e9m um guia com as 10 falhas de seguran\u00e7a mais comuns. Atualmente, s\u00e3o elas:<\/p>\n

        \n
      1. (SQL|NoSQL|OS|LDAP|*)-Injection<\/li>\n
      2. Autentica\u00e7\u00e3o mal-implementada<\/li>\n
      3. Exposi\u00e7\u00e3o n\u00e3o-planejada de dados sens\u00edveis<\/li>\n
      4. XXE (XML External Entities<\/em>)<\/li>\n
      5. Controle de acesso mal-implementado<\/li>\n
      6. Configura\u00e7\u00e3o ineficaz de seguran\u00e7a<\/li>\n
      7. Cross-site scripting (XSS)<\/em><\/li>\n
      8. Desserializa\u00e7\u00e3o insegura<\/li>\n
      9. Uso de componentes com vulnerabilidades conhecidas<\/li>\n
      10. Logging\u00a0<\/em>e Monitoramento insuficientes<\/li>\n<\/ol>\n

        Um padr\u00e3o para verifica\u00e7\u00e3o de sistemas seguros<\/h2>\nOWASP mant\u00e9m um padr\u00e3o para aplica\u00e7\u00e3o de verifica\u00e7\u00f5es\u00a0 de controles de seguran\u00e7a que, tamb\u00e9m, serve como refer\u00eancia para desenvolvedores e arquitetos verifiquem “conformidade” com pr\u00e1ticas de desenvolvimento seguro. Trata-se do ASVS<\/em> (Application Security Verification Standard<\/em>).\n
        \r\n\r\n\r\n\r\n
        \"\"<\/td>\r\n\"\" O objetivo principal do ASVS \u00e9 normalizar a abrang\u00eancia e o n\u00edvel de rigor dispon\u00edvel no mercado quando se trata de realizar a verifica\u00e7\u00e3o de seguran\u00e7a de aplicativos da Web usando um padr\u00e3o aberto comercialmente funcional. O padr\u00e3o fornece uma base para testar os controles t\u00e9cnicos de seguran\u00e7a do aplicativo, bem como quaisquer controles t\u00e9cnicos de seguran\u00e7a no ambiente, que s\u00e3o usados para proteger contra vulnerabilidades, como Cross-Site Scripting (XSS) e inje\u00e7\u00e3o de SQL.<\/em>\r\n

        OWASP<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

        SAMM – Um modelo de maturidade para garantia de seguran\u00e7a em software<\/h2>\n

        Eventualmente, mais do que desenvolver aplica\u00e7\u00f5es seguras, \u00e9 desej\u00e1vel desenvolver empresas que desenvolvem aplica\u00e7\u00f5es seguras. Para este fim, existe o SAMM.<\/p>\n

        \r\n\r\n\r\n\r\n
        \"\"<\/td>\r\n\"\" OWASP SAMM (Software Assurance Maturity Model) \u00e9 a estrutura OWASP para ajudar as organiza\u00e7\u00f5es a avaliar, formular e implementar uma estrat\u00e9gia para seguran\u00e7a de software, que pode ser integrada ao seu ciclo de vida de desenvolvimento de software (SDLC) existente. O OWASP SAMM \u00e9 adequado para a maioria dos contextos, se sua organiza\u00e7\u00e3o est\u00e1 principalmente desenvolvendo, terceirizando ou adquirindo software, ou se voc\u00ea est\u00e1 usando um m\u00e9todo em cascata, um m\u00e9todo \u00e1gil ou DevOps, o mesmo modelo pode ser aplicado.<\/em>\r\n

        OWASP<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

        \/\/ TODO<\/span><\/h2>\n

        Antes de avan\u00e7ar para o pr\u00f3ximo cap\u00edtulo, recomendo as seguintes reflex\u00f5es:<\/p>\n

          \n
        1. Seguran\u00e7a est\u00e1 relacionada entre os atributos de qualidade do sistema que est\u00e1 desenvolvendo? Com que prioridade?<\/li>\n
        2. Que restri\u00e7\u00f5es foram desenvolvidas a partir de seguran\u00e7a?<\/li>\n
        3. Voc\u00ea conhecia OWASP?<\/li>\n<\/ol>\n","protected":false},"featured_media":2231,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[],"sessoes":[58],"apendices":[],"capitulos":[35],"class_list":["post-3502","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","sessoes-secao-2","capitulos-capitulo-2-1"],"acf":[],"yoast_head":"\nFundamentos para a arquitetura de sistemas seguros \/ Cap\u00edtulo 10 v 1.1 - Manual do Arquiteto de Software<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Fundamentos para a arquitetura de sistemas seguros \/ Cap\u00edtulo 10 v 1.1 - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"Fen\u00f4menos com impacto mundial, como a pandemia de COVID-19, aceleraram a ado\u00e7\u00e3o de recursos e ferramentas digitais, bem como a frequ\u00eancia e a gravidade de incidentes. Legisla\u00e7\u00f5es ainda imaturas est\u00e3o entrando em vigor e a incerteza sobre o que \u00e9 obrigat\u00f3rio ou simplesmente respons\u00e1vel \u00e9 parte do cotidiano. No passado, era comum que apenas empresas […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/\" \/>\n<meta property=\"og:site_name\" content=\"Manual do Arquiteto de Software\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/eximiaco\" \/>\n<meta property=\"article:modified_time\" content=\"2024-01-11T20:58:22+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/flex-point-security-FNjGr9861i8-unsplash.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1024\" \/>\n\t<meta property=\"og:image:height\" content=\"576\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:site\" content=\"@eximiaco\" \/>\n<meta name=\"twitter:label1\" content=\"Est. tempo de leitura\" \/>\n\t<meta name=\"twitter:data1\" content=\"15 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/\",\"name\":\"Fundamentos para a arquitetura de sistemas seguros \/ Cap\u00edtulo 10 v 1.1 - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/flex-point-security-FNjGr9861i8-unsplash.jpg\",\"datePublished\":\"2021-11-14T15:03:14+00:00\",\"dateModified\":\"2024-01-11T20:58:22+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/flex-point-security-FNjGr9861i8-unsplash.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/flex-point-security-FNjGr9861i8-unsplash.jpg\",\"width\":1024,\"height\":576},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Volume 1\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Fundamentos para a arquitetura de sistemas seguros \/ Cap\u00edtulo 10 v 1.1\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"name\":\"Manual do Arquiteto de Software\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"pt-BR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\",\"name\":\"EximiaCo\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"width\":150,\"height\":150,\"caption\":\"EximiaCo\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/facebook.com\/eximiaco\",\"https:\/\/x.com\/eximiaco\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Fundamentos para a arquitetura de sistemas seguros \/ Cap\u00edtulo 10 v 1.1 - Manual do Arquiteto de Software","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/","og_locale":"pt_BR","og_type":"article","og_title":"Fundamentos para a arquitetura de sistemas seguros \/ Cap\u00edtulo 10 v 1.1 - Manual do Arquiteto de Software","og_description":"Fen\u00f4menos com impacto mundial, como a pandemia de COVID-19, aceleraram a ado\u00e7\u00e3o de recursos e ferramentas digitais, bem como a frequ\u00eancia e a gravidade de incidentes. Legisla\u00e7\u00f5es ainda imaturas est\u00e3o entrando em vigor e a incerteza sobre o que \u00e9 obrigat\u00f3rio ou simplesmente respons\u00e1vel \u00e9 parte do cotidiano. No passado, era comum que apenas empresas […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-11T20:58:22+00:00","og_image":[{"width":1024,"height":576,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/flex-point-security-FNjGr9861i8-unsplash.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"15 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/","name":"Fundamentos para a arquitetura de sistemas seguros \/ Cap\u00edtulo 10 v 1.1 - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/flex-point-security-FNjGr9861i8-unsplash.jpg","datePublished":"2021-11-14T15:03:14+00:00","dateModified":"2024-01-11T20:58:22+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/flex-point-security-FNjGr9861i8-unsplash.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/06\/flex-point-security-FNjGr9861i8-unsplash.jpg","width":1024,"height":576},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-a-arquitetura-de-sistemas-seguros-capitulo-10-v-1-1\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/"},{"@type":"ListItem","position":2,"name":"Volume 1","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/"},{"@type":"ListItem","position":3,"name":"Fundamentos para a arquitetura de sistemas seguros \/ Cap\u00edtulo 10 v 1.1"}]},{"@type":"WebSite","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","name":"Manual do Arquiteto de Software","description":"","publisher":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"pt-BR"},{"@type":"Organization","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization","name":"EximiaCo","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","logo":{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","width":150,"height":150,"caption":"EximiaCo"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/eximiaco","https:\/\/x.com\/eximiaco"]}]}},"_links":{"self":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1\/3502","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1"}],"about":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/types\/volume-1"}],"replies":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/comments?post=3502"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/2231"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=3502"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=3502"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=3502"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=3502"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=3502"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}