Desde que o PIX entrou em vigência, em novembro de 2020, os casos de sequestros-relâmpagos e de latrocínios, ou roubo seguido de morte, só aumentaram. Estima-se que, atualmente, há o dobro de ocorrências registradas.
Isso porque ficou muito fácil coagir um indivíduo a transferir todo o dinheiro que possui para outra conta. Afinal, todo mundo tem um aplicativo de banco instalado no celular.
Na maioria dos casos, os correntistas são vítimas de quadrilhas formadas por criminosos altamente especializados. Eles escolhem as pessoas, estudam suas rotinas, horários e comportamentos. Depois abordam, sequestram e coagem. No grupo há os especialistas em tecnologia e os laranjas que alugam suas contas bancárias para a recepção do dinheiro roubado.
Quem pensa que a transferência para uma conta bancária facilita a identificação dos criminosos está enganado. Normalmente, são contas falsas abertas em bancos digitais que fazem todo o processo de adesão pelo próprio celular, sem a necessidade da presença do novo correntista.
O presidente do Instituto Brasileiro de Defesa da Proteção de Dados Pessoais, Compliance e Segurança da Informação (Sigilo), Victor Hugo Pereira Gonçalves, lembra que é muito difícil um banco ressarcir o cliente em caso de seu dinheiro ser transferido para a conta corrente de criminosos. “Depende de cada banco ou de cada caso. Tecnologicamente, o PIX é uma grande evolução, mas o Banco Central falhou ao não prever que ocorrências desse tipo seriam comuns. É uma situação grave porque envolve não só o dinheiro, mas também a integridade física ou mesmo a vida dos cidadãos”.
Há dois anos, Gonçalves vem alertando a sociedade sobre os riscos de segurança que o PIX e os aplicativos bancários para celular trariam à sociedade. A aceitação pelo Banco Central (BC) das redes sociais Whatsapp e Facebook Pay como meios de pagamento só pioraram a situação, porque o público-alvo dos ladrões foi ampliado. “De posse do dispositivo móvel, os criminosos e até mesmo familiares mal intencionados têm acesso a dados particulares e também à conta bancária de suas vítimas”.
Para coibir a prática e proteger os correntistas, o BC está aprimorando os mecanismos de segurança do PIX. Inovações como bloqueio cautelar, que possibilita à instituição financeira bloquear os recursos transferidos por até 72h, sempre que houver indício de fraude na operação, é uma delas. Uma funcionalidade hoje facultativa, a notificação de infração passará a ser obrigatória. Outros mecanismos de proteção estão sendo criados e haverá ampliação da responsabilidade das instituições.
Mas tanto o presidente do Sigilo quanto especialistas em tecnologia não acreditam que essas medidas serão capazes de reduzir o número de crimes em função do PIX. Gonçalves aponta que o primeiro problema no uso diário do sistema é que ele pressupõe que todos os usuários possuem condições sociais, culturais e educacionais para lidarem efetivamente com as políticas de segurança de informação e privacidade recomendadas pelas instituições financeiras.
“É comum uma mãe pedir auxílio aos seus familiares para fazer algum tipo de pagamento ou transferência. Ou seja, só com esse exemplo podemos concluir que o não compartilhamento de senhas é uma quimera em situações comunitárias conhecidas no Brasil. O primeiro protocolo de segurança quebrado é exatamente esse. E mesmo que seja alguém muito consciente, quem negaria a senha diante de uma arma apontada para a cabeça?
Como as regras e os meios de segurança são incipientes para proteger os consumidores, a melhor forma de evitar ser sequestrado por alguém que deseja usar seu celular para esvaziar sua conta bancária é se prevenir. Veja abaixo algumas dicas do Instituto Sigilo, que podem ajudá-lo a proteger seus recursos financeiros.
– Os aplicativos de banco possibilitam que o usuário defina um valor máximo diário para transferência. Limite a pequenas quantias diárias.
– Se você tem alguma aplicação (poupança, CDB, etc.), não a deixe em baixa automática, pois isso torna mais fácil para o criminoso desviar todas as suas economias, além do que está na conta corrente.
– Não use uma única senha para tudo. Tenha uma senha para cada aplicativo.
– Não deixe os ícones dos aplicativos bancários na tela principal do celular. Deixá-los escondidos torna mais difícil para os ladrões encontrarem.
– Não deixe seu celular à mostra. Na rua, mantenha-o guardado e só o utilize quando estiver em um lugar seguro. Lembre-se, os criminosos contam com observadores nas ruas.
– Nem sempre o desvio de dinheiro é feito por criminosos. Familiares e amigos próximos podem se aproveitar da acessibilidade ao seu dispositivo móvel. Por isso, nunca compartilhe sua senha com outra pessoa.
– Se mesmo assim, seu celular for roubado, avise o quanto antes a operadora de telefonia, para que o aparelho seja bloqueado.
– Faça um boletim de ocorrência, pois isso o ajudará na batalha para ser ressarcido pelo seu banco.
Uma pesquisa da KPMG apontou que apenas 26% das companhias de petróleo e gás, que participaram do levantamento, aplicam tecnologias disponíveis. Alguns desses recursos são drones, visualização 3D, análise de dados e inteligência artificial utilizados para melhorar a forma como é feita a gestão de ativos, reduzindo o tempo de parada das unidades de processamento e a exposição a riscos. Essas são as principais conclusões do relatório denominado Nos trilhos da jornada digital que tem como objetivo mostrar de forma inédita como essa a indústria está lidando, na era pós-pandemia, com temas como a digitalização, uso de novas tecnologias e de dados.
Segundo o estudo, 29% dos entrevistados possuem uma equipe bem preparada para implantação de um processo de automação na indústria contra 48% que consideram não estarem aptos para aplicar esse método. Quase metade dos entrevistados (42%) afirma que as organizações estão prontas para uma mudança na matriz energética, sendo capazes de repor o portfólio de ativos pelos originados de fontes alternativas de energia.
“O relatório mostrou que um percentual pequeno de empresas de petróleo e gás utiliza as tecnologias disponíveis. Por isso, a indústria ainda tem muito a fazer com relação ao processo de transformação digital que pode aprimorar a gestão do negócio”, afirma o sócio do setor de energia e recursos naturais da KPMG, Anderson Dutra.
Na verdade, as empresas de petróleo e gás estão repensando as suas estratégias, buscando a oportunidade perfeita para reavaliar sua infraestrutura e fazer investimentos inteligentes em tecnologia para trazer seus sistemas para a era moderna. Por exemplo, os investimentos certos em tecnologia da informação e comunicação (TIC) e outras soluções digitais podem contribuir muito para aumentar a lucratividade e impulsionar a eficiência da organização para criar uma operação mais robusta.
De acordo com a McKinsey, investir em tecnologias digitais pode economizar às empresas de gás até 20% em despesas de capital e 5% em custos operacionais upstream. Com isso em mente, pode-se descrever algumas tecnologias nas quais as empresas de petróleo e gás estão cada vez mais investindo.
– Big data e análises – As empresas de petróleo e gás não podem se dar ao luxo de tomar decisões com base em seus instintos. Os projetos de perfuração são empreendimentos que exigem muito capital e maquinário pesado, e as organizações não podem se dar ao luxo de nenhuma margem de erro. É por isso que um número crescente de organizações está coletando mais e mais dados e executando análises para determinar o caminho mais inteligente a seguir. Com big data, pode ser mais fácil tomar as decisões certas.
– IIoT e computação de ponta – A internet das coisas industrial (IIoT) promete otimizar grande parte do setor de petróleo e gás, com dispositivos conectados coletando dados na origem e executando cargas de trabalho de computação de ponta para fornecer às organizações as informações de que precisam para garantir operações eficientes.
– Computação na nuvem – As empresas de petróleo e gás continuam a alavancar o poder da nuvem, aumentando a acessibilidade e disponibilidade de dados e, ao mesmo tempo, criando redundâncias em suas redes.
Inteligência artificial (IA) e aprendizado de máquina – A IA e o aprendizado de máquina estão mudando todos os setores, incluindo petróleo e gás. A IA, por exemplo, permite que as organizações transformem uma realidade prática acessível para qualquer pessoa.
– Robótica e drones – Devido às eficiências operacionais que fornecem, cada vez mais empresas de petróleo e gás estão investindo em robótica e drones. Esta categoria é projetada para ser a área de crescimento mais rápido para a indústria nos próximos três a cinco anos.
– Redes 5G – Na era digital, a velocidade é o que mais importa. É por isso que mais e mais organizações de petróleo e gás estão investindo em redes 5G que fornecem velocidade e conectividade incomparáveis.
– Ferramentas colaborativas – As empresas globais de petróleo e gás têm operações espalhadas por todo o mundo. Ao investir em ferramentas de colaboração, eles são capazes de garantir que todos os funcionários possam permanecer na mesma página – não importa onde estejam.
Para o setor, segundo alguns especialistas, fazer uso de conectividade digital avançada poderá otimizar o rendimento da perfuração e da produção, e melhorar a manutenção e as operações de campo. Esse processo pode agregar até US$ 250 bilhões de valor às operações upstream da indústria até 2030.
Desse valor, entre US$ 160 e US$ 180 bilhões poderiam ser realizados com a infraestrutura existente, enquanto US$ 70 bilhões adicionais poderiam ser desbloqueados com satélites em órbita terrestre baixa e tecnologias 5G de próxima geração. Além disso, as empresas poderiam reduzir custos, incluindo despesas operacionais e de capital, em 20% a 25% cento por barril, contando com conectividade para implantar as ferramentas digitais.
Para ajudar no processo de gestão das indústrias de petróleo e gás, a ABNT ISO/TS 29001 de 10/2010 – Indústrias do petróleo, gás natural e petroquímica – Sistemas de gestão da qualidade específicos do setor – Requisitos para organizações de fornecimento de produtos e serviços especifica requisitos para um sistema de gestão da qualidade, quando uma organização necessita demonstrar sua capacidade para fornecer produtos que atendam de forma consistente aos requisitos do cliente e requisitos estatutários e regulamentares aplicáveis. Esta Especificação Técnica tem como objetivo desenvolver um sistema de gestão da qualidade que promova a melhoria contínua, enfatizando a prevenção de defeitos e a redução da variabilidade e de perdas na cadeia de suprimento e na prestação de serviços.
Em conjunto com os requisitos específicos de clientes, define os requisitos fundamentais do sistema de gestão da qualidade para aqueles que adotarem esta especificação técnica que é baseada na NBR ISO 9001. Assim, pode-se evitar múltiplas auditorias de certificação e fornecer uma abordagem comum para um sistema de gestão da qualidade para as indústrias do petróleo, gás natural e petroquímica. O procedimento documentado deve identificar as funções responsáveis pela coleta e manutenção dos registros.
A NBR ISO 14224 de 10/2011 – Indústrias de petróleo e gás natural – Coleta e intercâmbio de dados de confiabilidade e manutenção para equipamentos fornece uma ampla base para a coleta de dados de confiabilidade e manutenção (RM) num formato-padrão para equipamentos em todas as instalações e operações nas indústrias de petróleo, gás natural e petroquímica durante o ciclo de vida operacional dos equipamentos. Ela descreve os princípios da coleta de dados e os termos e definições associados que constituem uma linguagem de confiabilidade que pode ser útil para a comunicação da experiência operacional.
Segundo o Instituto de Pesquisa Econômica Aplicada (Ipea), aproximadamente 1.400.000 de trabalhadores em atividade no setor de transporte de passageiros e de mercadorias no Brasil estão inseridos na chamada gig economy, termo que caracteriza relações laborais entre funcionários e empresas que contratam mão de obra para realizar serviços esporádicos e sem vínculo empregatício (tais como freelancers e autônomos), principalmente por meio de aplicativos.
O termo gig é um jargão, transladado da história da música norte-americana, utilizado desde o início do século XX para nomear os shows das bandas em datas específicas, geralmente nos fins de semana, e os músicos ficavam o restante da semana sem apresentação. No campo econômico, a gig economy também é conhecida como freelance economy ou mesmo economy on demand e caracteriza as relações laborais entre trabalhadores e empresas que contratam essa mão de obra para a realização de serviços esporádicos e, portanto, sem vínculo empregatício (tais como freelancers e autônomos).
Há um crescente uso das plataformas por aplicativos, como exemplo pode-se citar a ascensão do Uber, entre outros. De fato, percebe-se que um número maior de pessoas com empregos não tradicionais (como autônomos e trabalhadores temporários) tem crescido continuamente devido ao avanço tecnológico que facilita mais contratações de curto prazo.
A gig economy relacionada aos habilitados para aplicativos cresceu exponencialmente nos últimos anos, em que os empregos temporários por aplicativos servem como uma rede de segurança em tempos de crise econômica. As pessoas empregadas na Gig economy fornecem um serviço (como uma entrega para viagem ou uma corrida de táxi) sob demanda, por meio de uma plataforma ou um aplicativo (como Uber, inDriver ou 99) que conecta diretamente os consumidores com esses ofertantes, os quais são remunerados por cada rodada de serviços, cada show, que prestam, em vez de um salário fixo.
Dessa forma, o conceito de gig economy abarca as diversas formas de trabalho alternativo, englobando desde a prestação por serviços por aplicativos até o trabalho de freelancers, podendo ser pensado como um arranjo alternativo de emprego. Basicamente, pode-se supor que a gig economy possui estas características: ausência de vínculo formal na relação de trabalho (como a carteira de trabalho assinada); possibilidade de prestação de serviços para vários demandantes; e jornada esporádica de trabalho.
Até 31% do total estimado de 4.400.000 de pessoas alocadas no setor de transporte, armazenagem e correio no país estão nesse tipo de relação de trabalho. Os dados coletados mostram que, no primeiro trimestre de 2016, o número de pessoas ocupadas no transporte de passageiros na gig economy era de cerca de 840.000. No primeiro trimestre de 2018, esse quantitativo atingiu 1.000.000 de trabalhadores e chegou ao ápice no terceiro trimestre de 2019, com 1.300.000 de pessoas. Em 2020, houve uma redução, mas o número logo se estabilizou nos dois primeiros trimestres de 2021 em 1.100.000 de pessoas ocupadas em transporte de passageiros no regime de conta própria, valor 37% superior ao do início da série, em 2016.
Já para o transporte de mercadorias na gig economy, o número passou de 30.000 trabalhadores em 2016 para 278.000 no segundo trimestre de 2021, uma expansão de 979,8% no período. Além disso, a pesquisa do Ipea mostrou que, em média, entre o primeiro trimestre de 2016 e o segundo de 2021, 5% das pessoas ocupadas nas atividades de transporte de passageiros e de mercadorias, por conta própria, o faziam como um trabalho secundário.
O ápice dessa porcentagem foi no terceiro trimestre de 2019, antes da pandemia, quando 7,4% dos trabalhadores faziam dupla jornada com outra ocupação principal. Com a ascensão das plataformas de aplicativos para entregas de mercadorias ou transporte de passageiros e o consequente avanço tecnológico que facilita mais contratações de curto prazo, é possível perceber que a quantidade de pessoas com empregos não tradicionais (como autônomos e trabalhadores temporários) teve um crescimento exponencial nos últimos anos.
Dessa forma, a chamada explosão dos aplicativos de transportes permitiu o surgimento de uma gig economy por meio de tais plataformas digitais, que contribuíram para uma transformação no mercado de trabalho pela substituição de empregos em locais e horários fixos por formas mais flexíveis, com trabalhos sob demanda e remuneração por serviços.
Este documento se aplica apenas à segurança física para evitar que pessoas não autorizadas, ladrões ou invasores acidentais acessem fisicamente um prédio, sala, etc. O uso de serviços da Web e a funcionalidade de gestão de dispositivos estão fora do escopo deste documento.
O documento especifica apenas os dados e o fluxo de controle entre um cliente e os serviços sem referência a qualquer dispositivo físico, pois os serviços necessários para implementar um sistema de controle de acesso eletrônico compatível (electronic access control system – EACS) não são necessariamente implementados em um único dispositivo, ou seja, todos os serviços podem ser executados em um painel de controle, software agregador de eventos no PC, etc.
Conteúdo da norma
PREFÁCIO …….. …………………… 8
INTRODUÇÃO ……….. ……………. 10
1 Escopo …… …………………….. 11
2 Referências normativas …………… … 11
3 Termos e definições ……………… …. 12
4 Visão geral ……… ………………… 15
4.1 Geral ……………… …………… 15
4.2 Namespaces …………… ……. 16
4.3 Tratamento de erros ………. …… 17
5 Serviço de credencial ……. ……… 17
5.1 Geral …………. …………… 17
5.2 Capacidades de serviço ………………….. 18
5.2.1 Geral ……………………………. ……… 18
5.2.2 Estrutura de dados ServiceCapabilities ………………….. 18
8.7.2 Visão geral do evento (informativo) ……….. 99
8.7.3 Mudanças de status ………………………. 99
8.7.4 Mudanças de configuração …………………. 100
8.8 Exemplos …………………………. ………. 101
8.8.1 Geral ……………………………… ……. 101
8.8.2 Acesso 24 × 7 para equipe administrativa ………… 101
8.8.3 Acesso às segundas e quartas das 06:00 às 20:00 para o pessoal de limpeza………………. 101
8.8.4 Acesso de sexta-feira 18:00 às 07:00 para equipe de manutenção……………. 101
8.8.5 Acesso em dias de semana das 8h00 às 17h00 para funcionários…………….. 102
8.8.6 Acesso de 15 de janeiro de 2014 a 14 de janeiro de 2015, das 09:00 às 18:00 …………………………. ………. 103
8.8.7 Dias especiais, exemplo 1 ……………… 103
8.8.8 Dias especiais, exemplo 2 …………… 104
8.8.9 Dias especiais, exemplo 3 ……………….. 106
Anexo A (normativo) Esquemas XML da interface de controle de acesso………… …. 107
A.1 Serviço de credencial WSDL ……………………… 107
A.2 Serviço de regras de acesso WSDL ………………….. 127
A.3 Serviço de comportamento de autenticação WSDL……….. 137
A.4 Programar WSDL de serviço …………………………. 155
Anexo B (informativo) Mapeamento de funções obrigatórias na IEC 60839-11-1…………….174
Bibliografia …………………….. 182
Este documento torna possível construir um sistema de alarme e segurança eletrônica com clientes, normalmente um console de monitoramento, e dispositivos, normalmente uma unidade de controle de acesso, de diferentes fabricantes usando interfaces comuns e bem definidas. O documento especifica apenas os dados e o fluxo de controle entre um cliente e os serviços sem referência a qualquer dispositivo físico, pois os serviços necessários para implementar um sistema de controle de acesso eletrônico compatível (electronic access control system – EACS) não são necessariamente implementados em um único dispositivo, ou seja, todos os serviços podem ser executados em um painel de controle, software agregador de eventos no PC, etc.
Este documento não define a comunicação interna entre uma unidade de controle de acesso e seus componentes se eles forem implementados em um único dispositivo. Este documento é baseado no trabalho realizado pelo fórum aberto da indústria, o open network video interface forum (ONVIF). A especificação de credencial ONVIF, a especificação de regras de acesso ONVIF, o comportamento de autenticação ONVIF e a especificação ONVIF Schedule são compatíveis com este documento.
Este documento é acompanhado por um conjunto de definições de interface legíveis por computador (ver Anexo A): WSDL de serviço de credencial, consulte a Cláusula A.1; WSDL do serviço de regras de acesso, consulte a Cláusula A.2; WSDL do serviço de comportamento de autenticação, consulte a Cláusula A.3; agendar WSDL de serviço, consulte a Cláusula A.4. Devido às diferenças na terminologia usada na IEC 60839-11-1:2013 e IEC 60839-11-2:2014 e na especificação ONVIF na qual esta parte da IEC 60839 se baseia, um leitor deve prestar atenção especial aos termos e definições cláusula. Os serviços adicionais necessários para o monitoramento de portas e pontos de acesso (lados do portal) estão fora do escopo deste documento. Esses serviços são cobertos pela IEC 60839-11-32.
A NBR ISO/IEC-IEEE 12207 de 08/2021 – Engenharia de sistemas e software – Processos de ciclo de vida de software estabelece uma estrutura comum para processos de ciclo de vida de software, com terminologia bem definida, que pode ser referenciada pela indústria de software. Ele contém processos, atividades e tarefas que são aplicáveis durante a aquisição, fornecimento, desenvolvimento, operação, manutenção ou desativação de sistemas, produtos e serviços de software.
Estes processos de ciclo de vida são executados com sucesso por meio do envolvimento de stakeholders, com o objetivo final de alcançar a satisfação do cliente. Este documento é aplicável à aquisição, fornecimento, desenvolvimento, operação, manutenção e desativação de sistemas de software, produtos e serviços, e a parte de software de qualquer sistema (executados tanto interna como externamente a uma organização).
O software inclui a parte de software do firmware. Os aspectos de definição de sistema necessários para prover o contexto para produtos e serviços de software estão incluídos. Este documento também fornece os processos que podem ser empregados na definição, controle e melhoria dos processos de ciclo de vida de software dentro de uma organização ou projeto.
Os processos, atividades e tarefas deste documento também podem ser aplicados durante a aquisição de um sistema que contenha software, seja individualmente ou em conjunto com a ISO/IEC 15288:2015 – Systems and software engineering – System life cycle processes. No contexto deste documento e da ISO/IEC/IEEE 15288, há um continuum de sistemas desenvolvidos por humanos desde os que usam pouco ou nenhum software, até aqueles nos quais o software é o principal componente.
É raro encontrar um sistema complexo sem software e todos os sistemas de software exigem que os componentes do sistema físico (hardware) funcionem, ou seja, como parte do sistema de software de interesse. Assim, a escolha de quando aplicar este documento para os processos de ciclo de vida de software, ou a ISO/IEC/IEEE 15288: 2015 – Systems and software engineering–System life cycle processes, depende do sistema de interesse.
Os processos em ambos os documentos têm os mesmos propósitos e resultados de processo, mas diferem em atividades e tarefas para executar a engenharia de software ou a engenharia de sistemas, respectivamente. Assim, o propósito deste documento é fornecer um conjunto definido de processos para facilitar a comunicação entre adquirentes, fornecedores e outros stakeholders no ciclo de vida de um sistema de software.
Este documento foi escrito para adquirentes, fornecedores, desenvolvedores, integradores, operadores, mantenedores, gestores, gerentes de garantia de qualidade e usuários de sistemas, produtos e serviços de software. Ele pode ser usado por uma única organização de forma autoimposta ou em uma situação que envolva várias organizações. As partes podem ser da mesma organização ou de diferentes organizações, podendo variar para a realização de um acordo informal a um acordo formal.
Os processos neste documento podem ser usados como base para estabelecer ambientes de negócios, por exemplo, métodos, procedimentos, técnicas, ferramentas e pessoal treinado. O Anexo A fornece orientação normativa para a adaptação destes processos de ciclo de vida de software. Este documento é aplicável a todo o ciclo de vida de sistemas, produtos e serviços de software, incluindo concepção, desenvolvimento, produção, utilização, suporte e desativação, e à sua aquisição e fornecimento, sejam estes processos executados interna ou externamente a uma organização.
Os processos do ciclo de vida deste documento podem ser aplicados de forma concorrente, iterativa e recursiva a um sistema de software e de forma incremental aos seus elementos. Há uma grande variedade de sistemas de software em termos de propósito, domínio de aplicação, complexidade, tamanho, novidade, adaptabilidade, quantidade, localizações, vida útil e evolução.
Este documento descreve os processos que compõem o ciclo de vida de sistemas de software criados pelo homem. Portanto, aplica-se aos sistemas de software únicos, sistemas de software para ampla distribuição comercial ou pública e sistemas de software adaptáveis e customizados. Também se aplica a um sistema de software independente completo e aos sistemas de software que são incorporados e integrados a sistemas maiores, mais complexos e completos.
Este documento fornece um modelo de referência de processo caracterizado em termos de propósito e resultados de processo, que são consequência da execução bem-sucedida das tarefas da atividade. O Anexo B lista exemplos de artefatos e itens de informação que podem estar associados a vários processos. Este documento pode, portanto, ser usado como um modelo de referência para apoiar a avaliação de processo, conforme especificado na ISO/IEC 33002:2015.
O Anexo C fornece informações sobre o uso dos processos de ciclo de vida do software como um modelo de referência de processo. O Anexo D descreve os construtos do processo para uso no modelo de referência de processo. O Anexo I fornece a correspondência entre este documento e a ISO/IEC/IEEE 12207:2009 no nível de nome e resultado de processo.
Este documento não prescreve um modelo específico de ciclo de vida de software, metodologia de desenvolvimento, método, abordagem de modelagem ou técnica. Os usuários deste documento são responsáveis por selecionar um modelo de ciclo de vida para o projeto e por mapear os processos, atividades e tarefas deste documento naquele modelo. As partes também são responsáveis pela seleção e aplicação de metodologias, métodos, modelos e técnicas apropriados para o projeto.
Este documento não estabelece um sistema de gestão ou requer o uso de qualquer norma de sistema de gestão. No entanto, destina-se a ser compatível com o sistema de gestão da qualidade especificado pela NBR ISO 9001, com o sistema de gestão de serviços especificado pela NBR ISO/IEC 20000-1 (IEEE Std 20000-1) e com o sistema de gestão de segurança da informação especificado pela ISO/IEC 27000. Este documento não detalha itens de informação em termos de nome, formato, conteúdo explícito e mídia de registro. A ISO/IEC/IEEE 15289 aborda o conteúdo dos itens de informação de processo de ciclo de vida (documentação).
A complexidade dos sistemas de software aumentou a um nível sem precedentes. Isto levou a novas oportunidades, mas também aumentou os desafios para as organizações que criam e utilizam os sistemas. Estes desafios existem ao longo do ciclo de vida de um sistema e em todos os níveis de detalhes arquiteturais.
Este documento fornece uma estrutura de processo comum para descrever o ciclo de vida de sistemas criados por seres humanos, adotando uma abordagem de engenharia de software que é uma abordagem interdisciplinar e propicia a produção bem-sucedida de sistemas de software.
Ela foca a definição das necessidades dos stakeholders e a funcionalidade requerida no início do ciclo de desenvolvimento, a documentação dos requisitos, a execução da síntese do design e a validação do sistema, considerando o problema completo. Ela integra todas as disciplinas e grupos de especialidade em um esforço de equipe, formando um processo de desenvolvimento estruturado que passa do conceito à produção, operação e manutenção.
Ela considera tanto as necessidades de negócio quanto técnicas de todos os stakeholders, com o objetivo de fornecer um produto de qualidade que atenda às necessidades dos usuários e outros stakeholders aplicáveis. Este ciclo de vida abrange da concepção de ideias até a desativação de um sistema. Ela provê os processos para aquisição e fornecimento de sistemas.
Ela ajuda a melhorar a comunicação e a cooperação entre as partes que criam, utilizam e gerenciam sistemas de software modernos para que possam trabalhar de forma integrada e coerente. Além disso, a estrutura proposta contribui para a avaliação e melhoria dos processos do ciclo de vida.
Os processos neste documento formam um conjunto abrangente a partir do qual uma organização pode construir modelos de ciclo de vida de software apropriados para seus produtos e serviços. Uma organização, dependendo da sua finalidade, pode selecionar e aplicar um subconjunto apropriado para alcançar este propósito.
Este documento pode ser usado de uma ou mais das seguintes formas: por uma organização – para ajudar a estabelecer um ambiente de processos desejados. Estes processos podem ser sustentados por uma infraestrutura de métodos, procedimentos, técnicas, ferramentas e pessoal treinado. A organização pode então empregar este ambiente para executar e gerenciar seus projetos e evoluir sistemas de software ao longo as fases do ciclo de vida.
Dessa forma, este documento é usado para avaliar a conformidade de um ambiente declarado e estabelecido em relação ao que ele provê. Também pode ser usado por um projeto – para ajudar a selecionar, estruturar e utilizar os elementos de um ambiente estabelecido para fornecer produtos e serviços. Dessa forma, este documento é usado na avaliação da conformidade do projeto em relação ao ambiente estabelecido e declarado.
Pode ser utilizado por um adquirente e um fornecedor – para ajudar a desenvolver um acordo relativo a processos e atividades. Por meio desse acordo, os processos e atividades deste documento são selecionados, negociados, acordados e executados. Dessa forma, este documento é usado para orientar o desenvolvimento do acordo.
Pode ser usado por avaliadores de processo – para servir como um modelo de referência de processo utilizado na execução de avaliações de processo, que podem ser usadas para apoiar a melhoria do processo organizacional. Este documento fornece os requisitos para uma variedade processos adequados para uso durante o ciclo de vida de um sistema ou produto de software.
É reconhecido que projetos ou organizações específicos podem não precisar usar todos os processos fornecidos por este documento. Portanto, a implementação deste documento geralmente envolve a seleção e a declaração de um conjunto de processos adequados à organização ou projeto. Existem duas formas de reivindicar a conformidade com as disposições deste documento ‒ conformidade total e conformidade personalizada.
Existem dois critérios para reivindicar a conformidade total. Atingir qualquer destes critérios é suficiente para conformidade, embora o critério (ou critérios) escolhido (s) deva (m) ser declarado (s) na reivindicação. Reivindicar conformidade total com as tarefas afirma que todos os requisitos das atividades e tarefas do conjunto declarado de processos são alcançados.
Alternativamente, reivindicar conformidade total com os resultados afirma que todos os resultados requeridos do conjunto declarado de processos são alcançados. A conformidade total com resultados permite maior liberdade na implementação de processos e pode ser útil para implementar processos a serem usados no contexto de um modelo inovador de ciclo de vida.
Opções para conformidade são fornecidas para a flexibilidade necessária na aplicação deste documento. Cada processo tem um conjunto de objetivos (expressos como resultados) e um conjunto de atividades e tarefas que representam uma maneira de alcançar os objetivos. Os usuários que implementam as atividades e tarefas do conjunto declarado de processos podem afirmar conformidade total com as tarefas dos processos selecionados.
Alguns usuários, no entanto, podem ter variantes inovadoras de processos que atinjam os objetivos (ou seja, os resultados) do conjunto declarado de processos sem implementar todas as atividades e tarefas. Estes usuários podem afirmar conformidade total com os resultados do conjunto declarado de processos.
Os dois critérios – conformidade com tarefa e conformidade com resultado – não são necessariamente equivalentes, pois a execução específica de atividades e tarefas pode requerer, em alguns casos, um nível mais alto de capacidade do que apenas o alcance de resultados. Quando este documento é usado para auxiliar o desenvolvimento de um acordo entre um adquirente e um fornecedor, seções deste documento podem ser selecionadas para incorporação ao acordo, com ou sem modificação.
Neste caso, é mais apropriado que o adquirente e o fornecedor reivindiquem a conformidade com o acordo do que com este documento. Uma organização (por exemplo, pública, associação industrial, corporação) que impõe este documento, como condição comercial, pode especificar e tornar público o conjunto mínimo de processos, resultados, atividades e tarefas exigidos, que constituem a conformidade dos fornecedores com as condições do negócio.
Os requisitos deste documento são assinalados pelo uso do verbo deve. As recomendações são assinaladas pelo uso da expressão convém que. As permissões são assinaladas pelo uso do verbo pode. No entanto, apesar do termo usado, os requisitos de conformidade são selecionados conforme descrito anteriormente.
Uma reivindicação de conformidade total declara o conjunto de processos com os quais a conformidade é requerida. A conformidade total com resultados é alcançada pela demonstração que todos os resultados do conjunto declarado de processos foram alcançados. Nesta situação, as disposições para atividades e tarefas do conjunto declarado de processos são orientações e não requisitos, independentemente da expressão ou forma verbal usada na disposição.
Um uso pretendido deste documento é facilitar a avaliação e a melhoria do processo. Para este fim, os objetivos de cada processo são escritos na forma de resultados compatíveis com as disposições da ISO/IEC 33002 que fornece a avaliação dos processos deste documento, fornecendo uma base para melhorias. Os usuários que pretendem avaliar e melhorar processos podem usar os resultados de processo escritos no presente documento como o modelo de referência de processo requerido pela ISO/IEC 33002.
Uma reivindicação de conformidade total declara o conjunto de processos para os quais a conformidade é reivindicada. A conformidade total com tarefas é alcançada pela demonstração que todos os requisitos das atividades e tarefas do conjunto declarado de processos foram satisfeitos. Nesta situação, as disposições para os resultados do conjunto declarado de processos são orientações e não requisitos, independentemente da expressão ou forma verbal usada na disposição.
Uma reivindicação de conformidade total com tarefas pode ser apropriada em situações contratuais em que um adquirente ou um regulador requer um entendimento detalhado dos processos dos fornecedores. Quando este documento é utilizado como base para estabelecer um conjunto de processos que não se qualificam para conformidade total, as seções deste documento são selecionadas ou modificadas de acordo com o processo de adaptação prescrito no Anexo A.
O texto adaptado, para o qual a conformidade personalizada é reivindicada, é declarado. A conformidade personalizada é obtida pela demonstração de que foram alcançados os resultados, atividades e tarefas, conforme adaptados. As elaborações adicionais destes conceitos relativos à aplicação do gerenciamento do ciclo de vida podem ser encontradas nas ISO/IEC TS 24748-1, ISO/IEC TR 24748-2 e ISO/IEC TR 24748-3.
Os sistemas de software considerados neste documento são feitos, criados e utilizados por pessoas para fornecer produtos ou serviços em ambientes definidos para o benefício dos usuários e de outros stakeholders. Estes sistemas de software podem incluir os seguintes elementos de sistema: hardware, software, dados, pessoas, processos (por exemplo, processos para fornecer serviços aos usuários), procedimentos (por exemplo, instruções do operador), instalações, serviços, materiais e entidades.
Conforme vistos pelo usuário, eles são considerados produtos ou serviços. Este documento se aplica a sistemas para os quais o software é de primordial importância para os stakeholders. Este documento é baseado nos princípios gerais da engenharia de sistemas e engenharia de software.
É uma premissa fundamental deste documento que o software sempre exista no contexto de um sistema. Como o software não opera sem hardware, o processador no qual o software é executado pode ser considerado como parte do sistema. Como alternativa, o hardware ou serviços que hospedam o sistema de software e lidam com as comunicações com outros sistemas também podem ser vistos como sistemas habilitadores ou sistemas externos no ambiente operacional.
A percepção e a definição de um sistema de software específico, sua arquitetura e seus elementos dependem dos interesses e responsabilidades de um stakeholder. O sistema de interesse de um stakeholder pode ser visto como um elemento do sistema de interesse de outro stakeholder. Além disso, pode ser visto também como parte do ambiente de um sistema de interesse de outro stakeholder.
A seguir, são apresentados os principais pontos sobre as características de sistemas de interesse. Os limites definidos encapsulam necessidades significativas e soluções práticas; existem hierarquias ou outros relacionamentos entre os elementos do sistema. Uma entidade em qualquer nível no sistema de interesse pode ser vista como um sistema.
Um sistema compreende um conjunto integrado e definido de elementos de sistema subordinados e as pessoas podem ser vistas como usuários externos a um sistema e como elementos internos ao sistema (isto é, operadores); e um sistema pode ser visto isoladamente como uma entidade, isto é, um produto; ou como um conjunto de funções capazes de interagir com o ambiente ao seu redor, isto é, um conjunto de serviços. Quaisquer que sejam os limites escolhidos para definir o sistema, os conceitos neste documento são genéricos e permitem correlacionar ou adaptar instâncias individuais dos ciclos de vida aos princípios de sistema de um profissional.
Os processos do ciclo de vida neste documento são descritos em relação a um sistema de software que é composto por um conjunto de elementos que interagem (incluindo elementos de software), cada um dos quais pode ser implementado para satisfazer os respectivos requisitos especificados (figura abaixo). A responsabilidade pela implementação de qualquer elemento do sistema pode, portanto, ser delegada a outra parte por meio de um acordo.
O relacionamento entre o sistema de software e o conjunto completo de seus elementos geralmente pode ser representado mostrando os relacionamentos entre os elementos ‒ frequentemente descritos como uma hierarquia para o mais simples dos sistemas de interesse. A decomposição é uma abordagem para algumas atividades de software.
Outras abordagens incluem a orientação a objetos, na qual os elementos do sistema são dispostos em um mesmo plano (não hierárquica), como em um diagrama de rede. Para sistemas de interesse de software mais complexos, pode ser necessário considerar um futuro elemento como um sistema (que por sua vez é composto por outros elementos) antes que um conjunto completo possa ser definido de forma confiável.
Dessa forma, os processos apropriados de ciclo de vida de sistema são aplicados recursivamente a um sistema de interesse para resolver sua estrutura, até que elementos compreensíveis e gerenciáveis do sistema de software possam ser implementados (criados, adaptados, adquiridos ou reutilizados). Pode-se dizer que todo sistema de software tem um ciclo de vida. Um ciclo de vida pode ser descrito usando um modelo funcional abstrato que representa a conceituação de uma necessidade do sistema, sua realização, utilização, evolução e desativação.
Um sistema de software evolui no seu ciclo de vida como resultado de ações das atividades dos processos. Estas ações são executadas e gerenciadas por pessoas nas organizações. Os detalhes no modelo de ciclo de vida são expressos em termos destes processos, seus resultados, relacionamentos e sequência.
A IEC TR 62908-1-3:2021 – Touch and interactive displays – Part 1-3: General introduction of pen touch technology fornece as informações gerais sobre a tecnologia de toque de caneta com o objetivo de normalização. Este documento inclui uma visão geral da tecnologia de toque da caneta, características críticas de desempenho, problemas de medição de características e outras informações. O objetivo deste documento é fornecer uma visão geral dos diferentes produtos disponíveis na tecnologia de toque de caneta.
Conteúdo da norma
PREFÁCIO…………………… 4
INTRODUÇÃO……………… 6
1 Escopo………………………. 7
2 Referências normativas ………….. 7
3 Termos, definições e termos abreviados………… 7
3.1 Termos e definições ………………………….. 7
3.2 Termos abreviados …………………….. 7
4 Informações genéricas sobre a tecnologia de toque de caneta………………. 8
4.1 Geral ……………………………………. 8
4.2 Classificação……………….. 8
4.3 Tecnologia de detecção para caneta de toque………………….. 9
4.3.1 Geral ……………………… 9
4.3.2 Estrutura do painel do tipo resistivo e método de detecção …………… 10
4.3.3 Estrutura do painel do tipo capacitivo e método de detecção …………… 10
4.3.4 Estrutura do painel do tipo EMI e método de detecção………… 11
4.3.5 Estrutura do painel de tipo óptico e método de detecção…………. 12
4.3.6 Estrutura do painel do tipo ultrassônico e método de detecção ………………. 12
4.4 Arquitetura da caneta de toque……………… 13
4.4.1 Geral ……………………………. 13
4.4.2 Caneta stylus passiva ………………… 13
4.4.3 Caneta stylus ativa ……………………….. 14
5 Características de toque da caneta……………… 17
5.1 Geral ………………………….. 17
5.2 Características básicas do toque da caneta……………. 18
5.3 Características únicas e importantes do toque da caneta……………… 18
5.3.1 Geral ………………… 18
5.3.2 Velocidade de rastreamento…………………. 19
5.3.3 Conforto ao escrever ………………………… 19
5.3.4 Paralaxe de posição ………………………… 19
5.3.5 Área mínima e pressão mínima………….. 20
5.3.6 Sensibilidade à pressão……………………….. 20
5.3.7 Ângulo de inclinação……………………. 21
6 Exemplo de aplicação para cada tecnologia de toque de caneta………………………… 21
6.1 Geral ……………………………… 21
6.2 Caneta stylus passiva ………….. 21
6.3 Caneta stylus ativa ……………. … 21
6.3.1 Geral ………….. ……… 21
6.3.2 Caneta EMI ……………………. ………. 21
6.3.3 Caneta universal para tipo PCAP…………. 22
6.3.4 Tipo MPP ……………….. ……. 22
6.3.5 Tipo AP ……………… ……… 23
6.3.6 Caneta ES ativa tipo WA ……………….. 23
6.3.7 Tipo U (uso múltiplo) ……………………….. 23
7 Problema da futura tecnologia de toque de caneta……. 23
7.1 Geral……….. …………… 23
7.2 Velocidade de rastreamento………………. …. 23
7.3 Conforto ao escrever…………………………. …. 24
7.4 Uso combinado de toque de dedo e caneta………. 24
7.5 Área de rejeição da palma e relação posicional da caneta………………. 24
8 Colaboração de hardware e software…………….. 25
Bibliografia………………….. 26
Figura 1 – Estrutura do painel do tipo resistivo………… 10
Figura 2 – Estrutura do painel do tipo capacitivo…….. 11
Figura 3 – Estrutura do painel tipo EMI……………………… 12
Figura 4 – Estrutura do painel do tipo óptico……… 12
Figura 5 – Estrutura do painel do tipo ultrassônico …. 13
Figura 6 – Exemplo de ponta de fibra condutiva……. 14
Figura 7 – Exemplo de ponta de disco transparente…. 14
Figura 8 – Exemplo de caneta exclusiva…………………….. 14
Figura 9 – Exemplo de canetas EMI (Tipo WE) ……….. 15
Figura 10 – Paralaxe de posição ……………………… 20
Figura 11 – Pen tablet para animação/ilustração …… 22
Figura 12 – Exemplos de notebooks……………….. 23
Tabela 1 – Comparação entre dispositivos apontadores…… 8
Tabela 2 – Classificação da caneta de toque…………. 9
Tabela 3 – Correspondência entre o painel de toque e a caneta de toque …………….. 10
Tabela 4 – Comparação de desempenho de canetas de toque para PCAP/EMI ………….. 17
Tabela 5 – Características básicas do toque da caneta………………….. 18
Tabela 6 – Características únicas e importantes da caneta de toque ……………………….. 18
Com a disseminação dos smartphones nos últimos anos, a tecnologia de toque de dedo se espalhou por todo o mundo. O campo de popularização começou a partir dos smartphones e se espalhou de terminais de informação, como notebooks (laptops) e tablets para quiosques, caixas eletrônicos, equipamentos de venda na área de infraestrutura social, equipamentos médicos para uso profissional e itens relacionados à construção.
O toque do dedo apresenta vários desafios, como mau funcionamento devido ao ambiente de uso, como uso de luvas ou gotas de água, além da dificuldade de desenho fino com o toque do dedo, entrada de assinatura e assim por diante. Inicialmente, para o toque da caneta, o sistema operacional e o software aplicativo suportavam apenas a mesma função do toque do dedo, mas recentemente um novo conceito de tinta digital permitiu usar não apenas os dados da trajetória inserida, mas também os dados de progresso, como pressão de escrita, ângulo da caneta e desenho, sendo digitalizados e salvos junto com os dados de trajetória.
Isso significa que uma nova técnica com a entrada de caneta foi desenvolvida, que vai além da tecnologia convencional de entrada de toque do dedo. Com base nessa situação, este documento visa enfocar as questões relacionadas à padronização futura, resumindo os métodos de detecção do toque da caneta, os tipos de canetas sensíveis ao toque e as tecnologias correspondentes e as tendências de mercado da tecnologia do toque da caneta.
A NBR ISO/IEC 27035-3 de 07/2021 – Tecnologia da informação – Gestão de incidentes de segurança da informação – Parte 3: Diretrizes para operações de resposta a incidentes de TIC fornece as diretrizes para resposta a incidentes de segurança da informação em operações de tecnologia, informação e comunicação (TIC). Este documento faz isso abrangendo, em primeiro lugar, os aspectos operacionais da segurança de TIC em uma perspectiva de pessoas, processos e tecnologia. Em seguida, concentra-se ainda mais na resposta de incidente de segurança da informação em operações de TIC, incluindo detecção de incidentes de segurança da informação, relatórios, triagem, análise, resposta, contenção, erradicação, recuperação e conclusão.
Este documento não trata de operações de resposta a incidentes que não sejam de TIC, como perda de documentos em papel. É baseado na fase Detecção e geração de relatórios, na fase Avaliação e decisão e na fase Respostas do modelo Fases de gestão de incidentes de segurança da informação apresentado na ISO/IEC 27035-1:2016. Os princípios fornecidos neste documento são genéricos e pretendem ser aplicáveis a todas as organizações, independentemente do tipo, porte ou natureza. As organizações podem ajustar as disposições fornecidas neste documento de acordo com seu tipo, porte e natureza dos negócios em relação à situação de risco à segurança da informação. Também é aplicável às organizações externas que fornecem serviços de gestão de incidentes de segurança da informação.
Um incidente de segurança da informação pode ou não envolver TIC. Por exemplo, informações que se espalham involuntariamente por meio da perda de documentos em papel podem muito bem ser um incidente grave de segurança da informação, o que requer relatórios, investigações, contenções, ações corretivas e envolvimento da direção. Este tipo de gestão de incidentes geralmente é realizado, por exemplo, pelo CISO (Chief Information Security Officer) dentro da organização.
As orientações sobre a gestão de incidentes de segurança da informação podem ser encontradas na ISO/IEC 27035-1. Este documento, entretanto, considera apenas operações de resposta a incidentes relacionados à TIC, e não a incidentes de segurança da informação relacionados aos documentos em papel ou quaisquer outros incidentes não relacionados à TIC.
Sempre que o termo segurança da informação é usado neste documento, isso é feito no contexto da segurança da informação relacionada às TIC. As estruturas organizacionais para segurança da informação variam de acordo com o porte e o campo comercial das organizações. À medida que vários e numerosos incidentes ocorrem e estão aumentando (como incidentes na rede, por exemplo, intrusões, violações de dados e hackers), preocupações maiores com a segurança da informação são levantadas pelas organizações.
Convém que um ambiente seguro de TIC, configurado para suportar vários tipos de ataques (como DoS, worms e vírus) com equipamentos de segurança de rede, como firewalls, sistemas de detecção de intrusões (IDS) e sistemas de prevenção de intrusões (IPS), seja complementado com procedimentos operacionais claros para tratamento de incidentes, juntamente com estruturas de relatórios bem definidas dentro da organização.
Para assegurar a confidencialidade, a integridade e a disponibilidade da informação e para lidar eficientemente com incidentes, são necessários recursos para realizar operações de resposta a incidentes. Para este fim, convém que uma equipe de resposta a incidentes de segurança de computadores (ERISC) seja estabelecida para executar tarefas como atividades de monitoramento, detecção, análise e resposta para dados coletados ou eventos de segurança.
Estas tarefas podem ser auxiliadas por ferramentas e técnicas de inteligência artificial. Este documento suporta os controles da NBR ISO/IEC 27001:2013, Anexo A, relacionados à gestão de incidentes.
Nem todas as etapas deste documento são aplicáveis, pois dependem do incidente específico. Por exemplo, uma organização menor pode não usar todas as orientações deste documento, mas elas podem ser úteis para a organização de suas operações de incidentes relacionadas às TIC, especialmente se estiver operando o seu próprio ambiente de TIC.
Também podem ser úteis para as organizações menores que terceirizaram suas operações de TI para entender melhor os requisitos e a execução de operações de incidentes que convém que eles esperem de seus fornecedores de TIC. Este documento é particularmente útil para aquelas organizações que fornecem serviços de TIC que envolvem interações entre organizações de operações de incidentes, a fim de seguir os mesmos processos e termos.
Este documento também fornece uma melhor compreensão de como as operações de incidentes se relacionam com os usuários/clientes, a fim de determinar quando e como convém que essa interação ocorra, mesmo que isso não seja especificado. A ISO/IEC 27035-1:2016 abrange as cinco fases principais a seguir para a gestão de incidentes de segurança da informação: planejamento e preparação; detecção e geração de relatórios; avaliação e decisão; respostas; e lições aprendidas.
A ISO/IEC 27035-2:2016 abrange duas dessas cinco fases em detalhes, isto é, planejamento e preparação e lições aprendidas. Este documento abrange as três fases restantes em detalhes. Estas três fases restantes são coletivamente chamadas de operações de resposta a incidentes, que são o foco deste documento.
As disposições deste documento são baseadas nas fases detecção geração de relatórios, avaliação e decisão e respostas do modelo fases de gestão de incidentes de segurança da informação, apresentadas na ISO/IEC 27035-1. Coletivamente, estas fases são conhecidas como processo de operação de resposta a incidentes.
As fases do processo de operação de resposta a incidentes (que são detecção e geração de relatórios, avaliação e decisão e respostas, conforme estipulado na ISO/IEC 27035-1) incluem o seguinte: operações para identificação de incidentes; operações para avaliação e qualificação de incidentes; operações para coleta de inteligência de ameaças; operações para contenção, erradicação e recuperação de incidentes; operações para análise de incidentes; operações para geração de relatórios de incidentes.
O escopo da resposta a incidentes é determinado na ISO/IEC 27035-1. Convém que as operações de resposta a incidentes sejam vistas como um processo de negócios que permite que uma organização permaneça nos negócios. Especificamente, um processo de operação de resposta a incidentes é uma coleção de procedimentos destinados a identificar, responder e investigar possíveis incidentes de segurança de uma maneira que minimize o seu impacto e apoie a recuperação rápida.
A ISO/IEC 27035–1 mostra as cinco fases da gestão de incidentes de segurança da informação, como planejamento e preparação, detecção e geração de relatório, avaliação e decisão, respostas e lições aprendidas. Como mencionado anteriormente, este documento se concentra em um processo de operação de resposta a incidentes. Este processo pode ser caracterizado por um ciclo de vida de operações de resposta a incidentes, representado pelas fases internas (detecção, notificação, triagem, análise, resposta e geração de relatórios). Estas são representadas com mais detalhes na figura abaixo.
O ciclo de vida das operações de resposta a incidentes (detecção, notificação, triagem, análise, resposta e geração de relatório) pode ser mapeado para a ISO/IEC 27035-1, em cinco fases da gestão de incidentes de segurança da informação (planejamento e preparação, detecção e geração de relatórios, avaliação e decisão, respostas e lições aprendidas), conforme mostrado na tabela abaixo.
Os incidentes podem ocorrer de várias maneiras, e não é prático definir todos os incidentes e preparar o manual de resposta para cada tipo de incidente. Entretanto, existem tipos/fontes de ataque comuns que uma organização geralmente encontra e, portanto, convém que esteja preparada para lidar com esses ataques com eficiência.
Convém que os critérios sejam definidos para incidentes de segurança, de acordo com a importância (prioridade) das informações e sistemas de informação, impacto de cada incidente, escala de danos, classificação de alarmes e sua gravidade. Ver Anexo A para exemplos destes critérios.
A seguir, é apresentada uma lista não exaustiva de tipos/estímulos comuns de ataque que podem ser usados como base para definir procedimentos de tratamento de incidentes: mídia externa/removível: um ataque executado a partir de mídia removível (por exemplo, pen drive, CD) ou de um dispositivo periférico; atrito: um ataque que emprega métodos de força bruta para comprometer, degradar ou destruir sistemas, redes de relacionamento ou serviços (por exemplo, um DDoS destinado a prejudicar ou negar o acesso a um serviço ou aplicativo; um ataque de força bruta contra um mecanismo de autenticação, como senhas, CAPTCHAS ou assinaturas digitais); web: um ataque executado a partir de um website ou aplicativo baseado na web (por exemplo, um ataque de script entre sites usados para roubar credenciais ou redirecionar para um site que explore a vulnerabilidade do navegador e instale malware); e-mail: um ataque executado por meio de uma mensagem ou anexo de e-mail (por exemplo, código de exploração disfarçado de documento anexado ou um link para um site mal-intencionado no corpo de uma mensagem de e-mail).
Também inclui a interdição da cadeia de suprimentos: ataque antagônico aos ativos de hardware ou software que utilizam implantes físicos, cavalos de Troia ou backdoors, interceptando e modificando um ativo em trânsito pelo fornecedor ou varejista; representação: um ataque envolvendo a substituição de algo benigno por algo malicioso (por exemplo, falsificação, ataques intermediários, pontos de acesso sem fio não autorizados e ataques de injeção de SQL, todos envolvendo representação); uso impróprio: qualquer incidente resultante da violação das políticas de uso aceitável de uma organização por um usuário autorizado, excluindo as categorias acima (por exemplo, um usuário instala um software de compartilhamento de arquivos, levando à perda de dados confidenciais; ou um usuário executa atividades ilegais em um sistema); perda ou roubo de equipamento: a perda ou roubo de um dispositivo ou mídia de computação usado pela organização, como laptop, smartphone ou token de autenticação; outros: um ataque que não se encaixe em qualquer dessas categorias.
Ver o NIST Computer Security Incident Handling Guide 1 para obter mais diretrizes de classificação de incidentes e vetores de ataque. Um incidente compreende um ou vários eventos de segurança da informação relacionados que podem prejudicar os ativos de uma organização ou comprometer as suas operações, onde um evento de segurança da informação compreende uma ou várias ocorrências indicando uma possível violação ou falha dos controles de segurança da informação.
As operações de detecção de incidentes requerem que haja um ponto de contato (PoC) para receber informações e uma metodologia estabelecida para a equipe detectar eventos de segurança da informação. A detecção é importante porque inicia as operações de resposta a incidentes. O PoC é o papel ou a função organizacional que serve como o coordenador ou ponto focal das atividades da operação de incidentes.
Um evento de segurança da informação é relatado pelo Usuário/Fonte de alguma maneira, conforme mostrado na ISO/IEC 27035-1:2016, Figura 4. O principal objetivo do PoC é assegurar que um evento seja relatado o mais rápido possível à organização, para que o evento possa ser tratado com eficiência. Um fator crítico de sucesso é que o PoC possui as habilidades necessárias para determinar se um evento é realmente um evento relacionado à TIC e se o PoC é capaz de descrever o evento.
Convém que o evento então seja tratado posteriormente por um PoC e depois transferido para as operações de resposta a incidentes. A organização de um PoC pode ser diferente, dependendo do tamanho e da estrutura da organização, bem como da natureza dos negócios. Isso pode afetar como as operações de incidentes são informadas sobre o evento.
Entenda quais são os objetivos de controle, controles e diretrizes comumente aceitos para implementação de medidas para proteção de dados pessoais (DP), de acordo com os princípios de privacidade descritos na NBR ISO/IEC 29100, para o ambiente de computação em nuvem pública.
A NBR ISO/IEC 27018 de 03/2021 – Tecnologia da informação – Técnicas de segurança – Código de prática para proteção de dados pessoais (DP) em nuvens públicas que atuam como operadores de DP estabelece objetivos de controle, controles e diretrizes comumente aceitos para implementação de medidas para proteção de dados pessoais (DP), de acordo com os princípios de privacidade descritos na NBR ISO/IEC 29100, para o ambiente de computação em nuvem pública. Em particular, este documento especifica diretrizes com base na NBR ISO/IEC 27002, levando em consideração os requisitos regulatórios para a proteção de DP que podem ser aplicáveis dentro do contexto do (s) ambiente (s) de risco de segurança da informação de um provedor de serviços em nuvem pública.
Este documento é aplicável a todos os tipos e tamanhos de organizações, incluindo empresas públicas e privadas, entidades governamentais e organizações sem fins lucrativos, que fornecem serviços de tratamento de informações, como operadores de DP, por meio da computação em nuvem sob contrato para outras organizações. As diretrizes deste documento também podem ser pertinentes para organizações que atuam como controladores de DP. Os controladores de DP, entretanto, podem estar sujeitos à legislação, regulamentos e obrigações adicionais de proteção de DP, não aplicáveis aos operadores de DP. Este documento não se destina a abranger estas obrigações adicionais.
Os provedores de serviços em nuvem que tratam dados pessoais (DP) sob contrato com seus clientes têm que operar seus serviços de forma a permitir que ambas as partes atendam aos requisitos da legislação e aos regulamentos aplicáveis que abrangem a proteção de DP. Os requisitos e a forma como os requisitos são divididos entre o provedor de serviços em nuvem e seus clientes variam de acordo com a jurisdição legal e de acordo com os termos do contrato entre o provedor de serviços em nuvem e o cliente.
A legislação que regula como os DP podem ser tratados (ou seja, coletados, utilizados, transferidos e descartados) é algumas vezes referida como legislação de proteção de dados. Os DP são algumas vezes referidos como dados pessoais ou informações pessoais. As obrigações que incidem sobre um operador de DP variam de jurisdição para jurisdição, sendo um desafio para as empresas que fornecem serviços de computação em nuvem os operarem multinacionalmente.
Um provedor de serviços em nuvem pública é um operador de DP quando ele trata DP de acordo com as instruções de um cliente que utiliza serviços em nuvem. O cliente que utiliza serviços em nuvem, que tem o relacionamento contratual com o operador de DP em nuvem pública, pode variar de uma pessoa física, um titular de DP, tratando sua própria DP na nuvem, até uma organização, um controlador de DP, que trata o DP relativo a muitos titulares de DP.
O cliente que utiliza serviços em nuvem pode autorizar um ou mais usuários para serviço em nuvem associados a ele a utilizar os serviços disponibilizados sob seu contrato com o operador de DP em nuvem pública. Observar que o cliente que utiliza serviços em nuvem tem autoridade sobre o tratamento e uso dos dados.
Um cliente que utiliza serviços em nuvem, que também é um controlador de DP, pode estar sujeito a um conjunto mais amplo de obrigações que regulam a proteção de DP do que o operador de DP em nuvem pública. A manutenção da distinção entre o controlador de DP e o operador de DP depende de o operador de DP em nuvem pública não ter objetivos de tratamento de dados diferentes dos estabelecidos pelo cliente que utiliza serviços em nuvem em relação ao DP que ele trata e às operações necessárias para atingir os objetivos do cliente que utiliza serviços em nuvem.
Quando o operador de DP em nuvem pública estiver tratando de dados da conta do cliente que utiliza serviços em nuvem, ele pode estar atuando como um controlador de DP para esta finalidade. Este documento não abrange esta atividade. A intenção deste documento, quando utilizado em conjunto com os objetivos e controles de segurança da informação descritos na NBR ISO/IEC 27002, é criar um conjunto comum de categorias e controles de segurança que possam ser implementados por um provedor de serviços de computação em nuvem pública que atua como um operador de DP.
Este documento tem os seguintes objetivos: auxiliar o provedor de serviços em nuvem pública a atender às obrigações aplicáveis ao atuar como um operador de DP, se estas obrigações incidirem sobre o operador de DP diretamente ou por contrato; permitir que o operador de DP em nuvem pública seja transparente em assuntos relevantes, de modo que os clientes possam selecionar serviços de tratamento de DP baseados em nuvem bem controlados; auxiliar o cliente que utiliza serviços em nuvem e o operador de DP em nuvem pública a realizarem um acordo contratual; prover aos clientes que utilizam serviços em nuvem um mecanismo para o exercício de direitos e responsabilidades de auditoria e conformidade, nos casos em que auditorias individuais do cliente que utiliza serviços em nuvem de dados hospedados em um ambiente de servidor virtualizado (nuvem) com várias partes possam ser impraticáveis tecnicamente e possam aumentar os riscos a estes controles de segurança de rede física e lógica no local.
Este documento pode auxiliar ao prover uma estrutura de conformidade comum para os provedores de serviços em nuvem pública, especialmente aqueles que operam em um mercado multinacional. Ele é projetado para que as organizações o utilizem como uma referência para selecionar controles de proteção de DP dentro do processo de implementação de um sistema de gestão de segurança da informação de computação em nuvem, com base na NBR ISO/IEC 27001, ou como documento de orientação para implementação de controles de proteção de DP comumente aceitos por organizações que atuam como operadores de DP em nuvem pública.
Em particular, este documento foi baseado na NBR ISO/IEC 27002, levando em consideração o (s) ambiente (s) de risco específico (s) decorrente (s) dos requisitos de proteção de DP que podem ser aplicados aos provedores de serviços de computação em nuvem pública que atuam como operadores de DP. Normalmente, uma organização que implementa a NBR ISO/IEC 27001 está protegendo seus próprios ativos de informação.
Entretanto, no contexto dos requisitos de proteção de DP para um provedor de serviços em nuvem pública que atua como um operador de DP, a organização está protegendo os ativos de informação que são confiados a ela pelos seus clientes. A implementação dos controles da NBR ISO/IEC 27002 pelo operador de DP em nuvem pública é adequada para esta finalidade e necessária.
Este documento incrementa os controles da NBR ISO/IEC 27002 para acomodar a natureza distribuída do risco e a existência de uma relação contratual entre o cliente que utiliza serviços em nuvem e o operador de DP em nuvem pública. Este documento incrementa os controles da NBR ISO/IEC 27002 de duas maneiras: as diretrizes para implementação aplicáveis à proteção de DP em nuvem pública são providas para determinados controles existentes na NBR ISO/IEC 27002; e o Anexo A que fornece um conjunto de controles adicionais e diretrizes associadas, destinados a tratar dos requisitos de proteção de DP em nuvem pública não abordados pelo conjunto de controle existente na NBR ISO/IEC 27002.
A maioria dos controles e diretrizes deste documento também se aplicará a um controlador de DP. Entretanto, o controlador de DP, na maioria dos casos, estará sujeito às obrigações adicionais não especificadas neste documento. É essencial que uma organização identifique seus requisitos para a proteção de DP.
Existem três fontes principais de requisitos, conforme descrito a seguir. Os requisitos legais, estatutários, regulatórios e contratuais, em que uma fonte é representada pelos requisitos e obrigações legais, estatutários, regulatórios e contratuais que uma organização, seus parceiros comerciais, contratados e provedores de serviços têm que atender, e suas responsabilidades socioculturais e seu ambiente operacional.
Convém observar se a legislação, regulamentos e cláusulas contratuais realizados pelo operador de DP podem requerer a seleção de controles específicos e também podem necessitar de critérios específicos para a implementação destes controles. Estes requisitos podem variar de uma jurisdição para outra.
Os riscos que são outras fontes derivadas da avaliação de riscos à organização associados aos DP, levando em consideração a estratégia e os objetivos globais de negócio da organização. Por meio de uma avaliação de riscos, as ameaças são identificadas, a vulnerabilidade e a probabilidade de ocorrência são avaliadas e o impacto potencial é estimado.
A NBR ISO/IEC 27005 fornece as diretrizes sobre a gestão de riscos na segurança da informação, incluindo recomendações sobre a avaliação do risco, aceitação do risco, comunicação do risco, monitoramento do risco e análise crítica do risco. A NBR ISO/IEC 29134 fornece diretrizes sobre a avaliação do impacto de privacidade.
Quanto às políticas corporativas, enquanto muitos aspectos abrangidos por uma política corporativa são derivados de obrigações legais e socioculturais, uma organização também pode escolher, voluntariamente, ir além dos critérios que são derivados dos requisitos legais. Os controles podem ser selecionados deste documento (que inclui, por referência, os controles da NBR ISO/IEC 27002, criando um conjunto combinado de controle de referência para o setor ou aplicação especificado pelo escopo).
Se requerido, os controles também podem ser selecionados de outros conjuntos de controle, ou novos controles podem ser projetados para atender a necessidades específicas, conforme apropriado. Um serviço de tratamento de DP fornecido por um operador de DP em nuvem pública pode ser considerado uma aplicação de computação em nuvem em vez de um setor por si só. Entretanto, o termo específicos do setor é utilizado neste documento, uma vez que este é o termo convencional utilizado em outras normas da série ISO/IEC 27000.
A seleção de controles depende de decisões organizacionais com base nos critérios para aceitação do risco, nas opções para tratamento do risco e na abordagem geral da gestão de riscos aplicada à organização, e de acordos contratuais, de seus clientes e de seus fornecedores. A seleção de controles também está sujeita aos regulamentos e legislações nacionais e internacionais pertinentes.
Quando os controles neste documento não forem selecionados, é necessário que esta informação seja documentada, com justificativa pela omissão. Além disso, a seleção e a implementação de controles dependem da função real do provedor de nuvem pública no contexto de toda a arquitetura de referência de computação em nuvem (ver ISO/IEC 17789). Muitas organizações diferentes podem ser envolvidas no fornecimento de serviços de infraestrutura e de aplicação em um ambiente de computação em nuvem.
Em algumas circunstâncias, os controles selecionados podem ser exclusivos para uma categoria de serviço específica da arquitetura de referência de computação em nuvem. Em outros casos, pode haver funções compartilhadas na implementação de controles de segurança. Os acordos contratuais precisam especificar claramente as responsabilidades de proteção de DP de todas as organizações envolvidas em prover ou utilizar os serviços em nuvem, incluindo o operador de DP em nuvem pública, seus subcontratados e o cliente que utiliza serviços em nuvem.
Os controles neste documento podem ser considerados princípios de diretrizes e aplicáveis à maioria das organizações. Eles são explicados com mais detalhes a seguir, juntamente com as diretrizes para implementação. A implementação pode ser simplificada se os requisitos para a proteção de DP tiverem sido considerados no projeto do sistema de informações, serviços e operações do operador de DP em nuvem pública. Esta consideração é um elemento do conceito que é muitas vezes denominado Privacidade por Projeto.
Este documento pode ser considerado um ponto de partida para o desenvolvimento de diretrizes de proteção de DP. É possível que nem todos os controles e diretrizes contidos neste código de prática sejam aplicáveis. Além disso, controles e diretrizes adicionais não incluídos neste documento podem ser requeridos.
Quando documentos forem desenvolvidos contendo diretrizes ou controles adicionais, pode ser útil incluir referências cruzadas às Seções deste documento, quando aplicável, para facilitar a verificação da conformidade por auditores e parceiros de negócio. Os DP têm um ciclo de vida natural, desde a sua criação e origem, armazenamento, tratamento, uso e transmissão, até a sua eventual destruição ou obsolescência.
Os riscos aos DP podem variar durante o seu tempo de vida, porém a proteção de DP permanece importante em algumas etapas de todos os estágios. Os requisitos de proteção de DP precisam ser levados em consideração quando os sistemas de informações existentes e novos forem gerenciados por meio do seu ciclo de vida. Este documento possui uma estrutura similar à da NBR ISO/IEC 27002.
Nos casos em que os objetivos e controles especificados na NBR ISO/IEC 27002 são aplicáveis sem a necessidade de quaisquer informações adicionais, somente uma referência à NBR ISO/IEC 27002 é fornecida. Controles adicionais e diretrizes para implementação associadas, aplicáveis à proteção de DP para provedores de serviços de computação em nuvem, são descritos no Anexo A.
Nos casos em que os controles necessitam de orientações adicionais aplicáveis à proteção de DP para provedores de serviços de computação em nuvem, isto é provido sob o título Orientações para implementação da proteção de DP em nuvem pública. Em alguns casos, outras informações relevantes que incrementem as orientações adicionais são fornecidas, sob o título outras informações para proteção de DP em nuvem pública.
Conforme mostrado na tabela abaixo, estas orientações e informações específicas do setor estão incluídas nas categorias especificadas na NBR ISO/IEC 27002. Os números das Seções, que foram alinhados com os números das Seções correspondentes na NBR ISO/IEC 27002, estão indicados na tabela abaixo. Este documento deve ser utilizado em conjunto com a NBR ISO/IEC 27001, e os controles adicionais especificados no Anexo A devem ser considerados para adoção como parte do processo de implementação de um sistema de gestão de segurança da informação baseado na NBR ISO/IEC 27001.
De acordo com a NBR ISO/IEC 27002, cada categoria de controle principal contém: um objetivo do controle, declarando o que é para ser alcançado; e um ou mais controles que podem ser aplicados para alcançar o objetivo do controle. As descrições do controle estão estruturadas conforme o descrito a seguir.
O controle estabelece a declaração de controle específica para atender ao objetivo do controle. As diretrizes para implementação da proteção de DP em nuvem pública proveem informações mais detalhadas para apoiar a implementação do controle e atender aos objetivos do controle. As diretrizes podem não ser totalmente adequadas ou suficientes em todas as situações e podem não atender aos requisitos específicos de controle da organização. Os controles alternativos ou adicionais, ou outras formas de tratamento de risco (evitando, transferindo ou aceitando riscos) podem, portanto, ser apropriados.
Outras informações para proteção de DP em nuvem pública proveem informações adicionais que podem ser consideradas, como considerações legais e referências a outras normas. O controle e as diretrizes para implementação associadas e outras informações especificadas na NBR ISO/IEC 27002 são aplicáveis. As seguintes diretrizes específicas do setor também são aplicáveis.
Para as diretrizes para implementação da proteção de DP em nuvem pública, convém que as políticas de segurança da informação sejam incrementadas por uma declaração referente ao suporte e comprometimento em atingir o compliance com a legislação e os termos contratuais de proteção de DP aplicáveis acordados entre o operador de DP em nuvem pública e seus clientes (clientes que utilizam serviços em nuvem).
Convém que os acordos contratuais atribuam claramente as responsabilidades entre o operador de DP em nuvem pública, seus subcontratados e o cliente que utiliza serviços em nuvem, levando em consideração o tipo de serviço em nuvem em questão (por exemplo, um serviço de uma categoria IaaS, PaaS ou SaaS da arquitetura de referência de computação em nuvem).
Por exemplo, a atribuição de responsabilidade pelos controles da camada de aplicação pode diferir, dependendo se o operador de DP em nuvem pública está fornecendo um serviço de SaaS ou, em vez disso, está fornecendo um serviço de PaaS ou IaaS sobre o qual o cliente que utiliza serviços em nuvem pode construir ou estender em camadas suas próprias aplicações. Em algumas jurisdições, o operador de DP em nuvem pública está diretamente sujeito à legislação de proteção de DP.
Em outros locais, a legislação de proteção de DP é aplicável somente ao controlador de DP. Um mecanismo para assegurar que o operador de DP em nuvem pública está obrigado a apoiar e gerenciar o compliance é provido pelo contrato entre o cliente que utiliza serviços em nuvem e o operador de DP em nuvem pública.
O contrato pode requerer conformidade com auditoria independente, aceitável ao cliente que utiliza serviços em nuvem, por exemplo, por meio da implementação dos controles pertinentes neste documento e na NBR ISO/IEC 27002. Para as diretrizes para implementação da proteção de DP em nuvem pública, convém que medidas sejam implementadas para conscientizar os funcionários da organização, quando pertinente, sobre as possíveis consequências ao operador de DP em nuvem pública (por exemplo, consequências legais, perda de negócio e danos à marca ou de reputação), ao membro da equipe (por exemplo, consequências disciplinares) e ao titular de DP (por exemplo, consequências físicas, materiais e emocionais) na violação das regras e procedimentos de privacidade ou de segurança, especialmente aqueles que tratam da manipulação de DP.
Para as outras informações para proteção de DP em nuvem pública, em algumas jurisdições, o operador de DP em nuvem pública pode estar sujeito a sanções legais, incluindo multas substanciais diretamente da autoridade local de proteção de DP. Em outras jurisdições, convém que o uso de normas como este documento, na preparação do contrato entre o operador de DP em nuvem pública e o cliente que utiliza serviços em nuvem, auxilie a estabelecer uma base para sanções contratuais por violação de regras e procedimentos de segurança.
No contexto das categorias de serviço da arquitetura de referência de computação em nuvem, o cliente que utiliza serviços em nuvem pode ser responsável por alguns ou todos os aspectos do gerenciamento de acesso para usuários que utilizam serviços em nuvem sob seu controle. Quando apropriado, convém que o operador de DP em nuvem pública permita que o cliente que utiliza serviços em nuvem gerencie o acesso dos usuários sob seu controle, por exemplo, fornecendo direitos administrativos para gerenciar ou encerrar o acesso.
Convém que os procedimentos para registro e cancelamento do usuário tratem a situação quando o controle de acesso do usuário estiver comprometido, como a corrupção ou o comprometimento de senhas ou outros dados de registro do usuário (por exemplo, como resultado de uma divulgação involuntária). As jurisdições individuais podem impor requisitos específicos relativos à frequência de verificações para credenciais de autenticação não utilizadas.
Convém que as organizações que operam nessas jurisdições assegurem que elas atendam a estes requisitos. Convém que o operador de DP em nuvem pública forneça informações ao cliente que utiliza serviços em nuvem referentes às circunstâncias em que ele utiliza a criptografia para proteger os DP que ele trata.
Convém que o operador de DP em nuvem pública também forneça informações ao cliente que utiliza serviços em nuvem sobre quaisquer capacidades que ele fornece que possam auxiliar o cliente que utiliza serviços em nuvem a aplicar sua própria proteção criptográfica. Em algumas jurisdições, pode ser requerido aplicar a criptografia para proteger tipos específicos de DP, como dados de saúde relativos a um titular de DP, números de registro de residentes, números de passaporte e números de licença de motorista.
Deve-se entender que a organização no escopo do SGS pode ser parte de uma organização maior, por exemplo, um departamento de TI de uma grande corporação. A organização gerencia e entrega serviços aos clientes e pode também ser referida como um provedor de serviço.
A NBR ISO/IEC 20000-2 de 01/2021 – Tecnologia da informação – Gestão de serviço – Parte 2: Orientação para aplicação de sistemas de gestão de serviço fornece orientação na aplicação de um sistema de gestão de serviço (SGS) baseado na ABNT NBR ISO/IEC 20000-1. Ele fornece exemplos e recomendações para permitir às organizações a interpretar e aplicar ABNT NBR ISO/IEC 20000-1, incluindo referências a outras partes da ISO/IEC 20000 e outras normas pertinentes. A figura abaixo ilustra um SGS com o conteúdo das seções da NBR ISO/IEC 20000-1. Isso não representa uma estrutura hierárquica, sequência ou níveis de autoridade.
A estrutura de seções visa fornecer uma apresentação coerente de requisitos, em vez de um modelo para documentar políticas, objetivos e processos de uma organização. Cada organização pode escolher como combinar os requisitos dentro de processos. O relacionamento entre cada organização e seus clientes, usuários e outras partes interessadas influencia como os processos são implementados.
No entanto, um SGS conforme desenhado por uma organização não pode excluir qualquer dos requisitos especificados na NBR ISO/IEC 20000-1. O termo serviço, conforme usado neste documento, se refere aos serviços no escopo do SGS. O termo organização, conforme usado neste documento, se refere à organização no escopo do SGS.
A organização no escopo do SGS pode ser parte de uma organização maior, por exemplo, um departamento de TI de uma grande corporação. A organização gerencia e entrega serviços aos clientes e pode também ser referida como um provedor de serviço. Qualquer uso dos termos serviço ou organização com um intuito diferente é distinguido claramente neste documento.
O termo entregue, conforme usado neste documento, pode ser interpretado como todas as atividades do ciclo de vida de serviço que são executadas além das atividades operacionais diárias. Atividades do ciclo de vida de serviço incluem planejamento, desenho, transição, entrega e melhoria. A orientação neste documento é genérica e visa ser aplicável a qualquer organização aplicando um SGS, independentemente do tipo ou tamanho da organização, ou a natureza dos serviços entregues.
Enquanto isto pode ser usado independentemente do tipo ou tamanho da organização, ou a natureza dos serviços entregues, a NBR ISO/IEC 20000-1 tem suas raízes na TI. É destinada ao gerenciamento de serviços que usem tecnologia e informação digital. O exemplo dado neste documento ilustra uma variedade de usos da ISO/IEC 20000-1.
O provedor de serviço presta contas pelo SGS e, portanto, não pode pedir a outra parte para cumprir os requisitos das Seções 4 e 5 da NBR ISO/IEC 20000-1:2020. Por exemplo, a organização não pode pedir a outra parte para fornecer a Alta Direção e demonstrar comprometimento da Alta Direção ou demonstrar o controle de partes envolvidas no ciclo de vida de serviço.
Algumas atividades da ISO/IEC20000-1:2020, Seções 4 e 5 podem ser executadas por outra parte, sob a gestão da organização. Por exemplo, uma organização pode pedir para outra parte para criar o plano de gestão de serviço inicial como um documento principal para o SGS. O plano, uma vez criado e acordado, é de responsabilidade direta e é mantido pela organização.
Nestes exemplos, a organização está usando outras partes para atividades curtas e específicas. A organização tem a responsabilização, autoridade e responsabilidade pelo SGS. A organização pode, portanto, demonstrar evidência de cumprimento de todos os requisitos da NBR ISO/IEC 20000-1:2018, Seções 4 e 5.
Para a ISO/IEC 20000-1:2020, Seções 6 a 10, uma organização pode mostrar evidência de cumprir ela mesma todos os requisitos. Alternativamente, uma organização pode mostrar evidência de reter a prestação de contas pelos requisitos quando outras partes estão envolvidas em cumprir os requisitos da ISO/IEC 20000-1:2020, Seções 6 a 10.
O controle de outras partes envolvidas no ciclo de vida pode ser demonstrado pela organização (ver 8.2.3). Por exemplo, a organização pode demonstrar evidência de controles para outra parte que esteja fornecendo componentes ou operando a central de serviço incluindo o processo de gerenciamento de incidente. A organização não pode demonstrar conformidade aos requisitos da NBR ISO/IEC 20000-1:2020 se outras partes forem usadas para prover ou operar todos os serviços, componentes de serviço ou processos dentro do escopo do SGS.
No entanto, se outras partes fornecerem ou operarem apenas alguns dos serviços, componentes de serviço ou processos, a organização pode normalmente demonstrar evidência de cumprimento dos requisitos especificados na ABNT NBR ISO/IEC 20000-1. O escopo deste documento exclui a especificação de produtos ou ferramentas. No entanto, a NBR ISO/IEC 20000-1 e este documento podem ser usados para ajudar com o desenvolvimento ou na aquisição de produtos ou ferramentas que apoiem a operação de um SGS.
Este documento provê orientação para estabelecer, implementar, manter e melhorar continuamente um sistema de gestão de serviço (SGS). Um SGS suporta o gerenciamento do ciclo de vida do serviço, incluindo o planejamento, desenho, transição, entrega e melhoria de serviços, que cumprem requisitos acordados e entregam valor para clientes, usuários e para a organização que entrega os serviços.
A adoção de um SGS é uma decisão estratégica para uma organização e é influenciada pelos objetivos da organização, pelo órgão de governança, por outras partes envolvidas no ciclo de vida do serviço e pela necessidade por serviços efetivos e resilientes. A orientação neste documento se alinha à NBR ISO/IEC 20000-1:2020. Este documento (NBR ISO/IEC 20000-2) é intencionalmente independente de orientação ao gerenciamento de qualquer tipo específico de serviço.
A organização pode usar uma combinação de modelos geralmente aceitos e sua própria experiência. A melhoria para gerenciamento de serviço pode usar metodologias de melhoria comuns e aplicá-las ao SGS e aos serviços. Ferramentas apropriadas para gerenciamento de serviços podem ser usadas para suportar o SGS. A implementação e a operação de um SGS incluem a visibilidade no dia a dia, controle de serviço e melhoria contínua, resultando em grande eficácia e eficiência. A melhoria para gerenciamento de serviço se aplica ao SGS e aos serviços.
A estrutura de seções neste documento (por exemplo, numeração de seção e sequência) se alinha com a NBR ISO/IEC 20000-1:2020 e os termos usados neste documento se alinham com a NBR ISO/IEC 20000-1:2020 e a ISO/IEC 20000-10:2018. A organização determina as questões internas e externas pertinentes ao seu propósito que afetam sua habilidade de alcançar os resultados pretendidos do SGS.
O propósito disso é definir o contexto, determinando aquelas questões que forem pertinentes ao propósito da organização e que influenciem sua habilidade de alcançar os resultados pretendidos do SGS. Estes resultados incluem a entrega de valor aos seus clientes.
As questões podem variar em, por exemplo, interna ou externa, positiva ou negativa. Todas as questões em conjunto fornecem o contexto básico em que a organização estabelece seu SGS. A palavra questão neste contexto pode ser fatores ou atributos que tenham um impacto positivo ou negativo.
Estes são tópicos importantes, fatores ou atributos para a organização no contexto de sua habilidade para entregar serviços de uma qualidade acordada aos seus clientes. Para implementar um SGS com sucesso, a organização identifica e documenta seu contexto interno e externo. O contexto inclui a natureza da organização, as necessidades e expectativas de outras partes interessadas que tenham um interesse no SGS e no escopo do SGS em si.
Baseado em uma compreensão destas questões, o SGS pode ser estabelecido. Já no estágio de planejamento, convém que a organização estabeleça como a NBR ISO/IEC 20000-1 é aplicável ao contexto da organização, de forma que o escopo inicial do SGS possa ser documentado. A falha na identificação do contexto, das partes interessadas e do escopo pode resultar em um SGS sem sucesso ou ineficiente.
Devido às questões internas e externas poderem mudar, a organização pode analisar criticamente seu contexto em intervalos planejados e por meio de análises críticas pela direção. Como exemplo, pode-se dizer que as questões internas podem incluir políticas, recursos, capacidades, pessoas, habilidades e conhecimento, estrutura organizacional, governança, cultura, demandas internas de clientes e finanças.
Questões externas podem incluir mercado, política, economia e influência ambiental, competição, leis e regulamentações, demandas externas de clientes e a probabilidade de eventos que possam afetar os serviços. Uma lista de questões internas e externas que afetem o SGS é desenvolvida e convém que seja documentada.
O estabelecimento do contexto da organização é concluído no nível da Alta Direção, que pode ter a assistência de analistas técnicos e de negócio. Dessa forma, a organização determina as partes interessadas relevantes ao SGS e aos serviços e seus requisitos. O propósito disso é assegurar que a organização identifique requisitos de partes interessadas pertinentes para apoiar o SGS a entregar serviços.
Uma parte interessada é uma pessoa ou grupo que pode afetar ou ser afetado por uma decisão ou atividade relacionada ao SGS. Elas podem ser internas ou externas à organização. Uma parte interessada também pode ser chamada de stakeholder. Exemplo: partes interessadas podem incluir clientes e representantes de clientes, altos executivos, representantes da gestão, gestão de contas, pessoal, funções de suporte dentro da organização (por exemplo, suporte de tecnologia, recursos humanos, instalações, jurídico, recrutamento, compras), fornecedores, parceiros, órgãos reguladores, auditores, associações comerciais e profissionais e concorrentes.
A organização identifica as partes interessadas e sua relevância ao atingimento de objetivos de gestão de serviço ou à entrega de serviços, incluindo seus requisitos para o SGS ou os serviços. Uma parte interessada pode afetar o desempenho e efetividade do SGS e os serviços, influenciar o mercado ou criar e mitigar riscos. Os requisitos de partes interessadas podem incluir o seguinte: requisitos de serviço, como metas de nível de serviço, capacidade, desempenho, requisitos de nível de serviço, continuidade de serviço, segurança da informação ou requisitos de disponibilidade; requisitos legais e regulamentares impostos por autoridades externas, como leis e regulamentos nacionais ou regionais; e obrigações contratuais para parceiros, clientes ou fornecedores.
A organização documenta uma lista de partes interessadas com seus interesses específicos e seus requisitos para o SGS e os serviços. A identificação de partes interessadas é concluída no nível da Alta Direção, que pode ter a assistência de analistas técnicos e de negócio.
A organização determina os limites e a aplicabilidade do SGS para estabelecer seu escopo. O propósito disso é usar a informação coletada sobre as questões e os requisitos das partes interessadas para definir exatamente qual parte da organização e quais serviços serão incluídos dentro do SGS. Estabelecer o escopo é, portanto, uma atividade principal que determina o fundamento necessário para as outras atividades na implementação do SGS.
A organização considera as seguintes entradas ao documentar o escopo do SGS: as questões internas e externas; as necessidades e expectativas de partes interessadas internas e externas; quais serviços ou tipos de serviços são oferecidos ou todos os serviços, por exemplo: um único serviço, grupo de serviços ou todos os serviços; os serviços de TI, serviços em nuvem; os serviços de tecnologia para apoiar gerenciamento de instalações, terceirização de processos de negócio; os serviços de tecnologia para apoiar quaisquer setores de negócio, como telecomunicações, finanças, varejo, turismo, utilidades; o número e tipo de clientes, como por exemplo, um único cliente, um setor específico de clientes, clientes externos ou internos; as localidades em que os serviços serão entregues.
Os serviços a ser considerados podem ser todos ou alguns dos serviços que são acordados para estar no escopo do SGS. Os serviços no escopo do SGS podem ser todos ou alguns dos serviços entregues pela organização. Os serviços no escopo do SGS podem estar listados individualmente ou agrupados.
O nome da organização que gerencia e fornece os serviços está incluso; no entanto, não convém que a declaração de escopo inclua os nomes de outras partes contribuindo para a entrega do serviço, como parceiros de terceirização. O propósito das atividades requeridas é assegurar que todos os elementos requeridos estejam montados para estabelecer, implementar, manter e melhorar continuamente o SGS.
Uma vez que, neste contexto, as partes interessadas, os seus requisitos e o escopo tenham sido acordados, a organização decide como os requisitos na NBR ISO/IEC 20000-1 serão implementados na forma de processos. Por exemplo, os processos no SGS irão refletir exatamente as Seções na NBR ISO/IEC 20000-1 ou serão combinados, separados ou nomeados de maneira diferente?
Para ganhar o máximo valor dos processos, é essencial manter os processos existentes. Uma abordagem para uma rotina de avaliação de processos irá beneficiar a organização. Enquanto os processos são implantados e implementados, análises críticas de rotina incluem uma análise crítica de seu desempenho para otimizar os resultados do processo.
Os planos e aspirações da organização podem ser considerados ao estabelecer e implementar o SGS, de forma que a manutenção e a melhoria possam ser executadas eficientemente. A organização documenta o SGS para cumprir os requisitos da NBR ISO/IEC 20000-1:2020, 7.5. A Alta Direção fornece a base e a autoridade para proceder com o estabelecimento do SGS. A responsabilidade por estabelecer o SGS pode então ser delegada para pessoal autorizado na organização.
qualidadeonline's Blog 