Gestión De Proyectos
Gestión De Riesgos
29 de septiembre de 2023
Gestión de riesgos para el sitio web de un instituto de educación
DOI: 10.22167/2675-6528-20230069
E&S 2023,4: e20230069
Fabio Luis Gonzaga; Aline Bigaton
Según el Project Management Institute (PMI)[1], una asociación global de gerentes de proyectos, el riesgo es todo evento o condición de incertidumbre que, cuando ocurre, puede causar impactos positivos o negativos en el objetivo del proyecto. Los efectos negativos pueden representar amenazas; los positivos, oportunidades. Todos los proyectos tienen riesgos, y corresponde a los miembros del equipo del proyecto identificarlos para minimizar o evitar las amenazas y maximizar las oportunidades. La gestión de riesgos es un proceso que ayuda a identificar, analizar y planificar respuestas, además de monitorear estos riesgos[2].
Una encuesta realizada por el Centro Regional de Estudios para el Desarrollo de la Sociedad de la Información (Cetic.br) mostró que el 54% de las empresas brasileñas tienen sitio web y el 57% utilizan Internet como medio para realizar ventas[3]. Las empresas cuyo sitio web es un componente crítico para el negocio deben gestionar los riesgos relacionados con el costo por tiempo de inactividad del sitio web de la misma manera que lo hacen para protegerse de pérdidas como errores, omisiones, indemnizaciones laborales, entre otras[4].
La web sirve a muchas organizaciones como parte integral de sus operaciones diarias para atraer clientes, comunicarse con proveedores y generar ingresos; como resultado, el costo de las fallas en la disponibilidad de sus servicios puede ser significativo[5]. Según Plesky[6], el tiempo de inactividad puede definirse como el período en el que el sitio web está completamente inaccesible o incapaz de realizar sus funciones principales, causando, incluso por un breve período, insatisfacción a los clientes. Esto puede contribuir a la caída en los motores de búsqueda en línea y resultar en la pérdida de clientes y de ingresos, perjudicando la reputación de la marca.
Entre los días 19 y 23 de febrero de 2022, los sitios web del grupo Americanas S.A., responsable de los “marketplaces” de Lojas Americanas y Submarino, presentaron inestabilidades de acceso y quedaron fuera de servicio, debido a un incidente de seguridad. Según la consultora Economatica, se estima que la compañía haya tenido una pérdida de R$ 3,4 mil millones[7] en función de lo ocurrido.
Los sitios web pueden sufrir fallos permanentes, intermitentes o transitorios, que afectan a la plataforma en su totalidad o parcialmente. Los fallos permanentes persisten hasta que el problema se repara; los fallos transitorios eventualmente desaparecen sin una intervención aparente; y los fallos intermitentes son transitorios y ocurren ocasionalmente, como, por ejemplo, cuando hay una sobrecarga en el sistema. Las causas de los fallos pueden categorizarse como errores de software, de hardware, ambientales o humanos, además de violaciones de seguridad[5].
Según Pertet y Narasimhan[5], la falla se manifiesta a partir de los efectos que son perceptibles para los usuarios; se pueden citar como ejemplos excepciones del sistema y violaciones de acceso, que producen mensajes de error. Otro tipo de indicación de falla está relacionado con resultados incorrectos, como la visualización de una página errónea o en blanco, o la presencia de información incompleta. Generalmente este tipo de falla se descubre solo después de las quejas de los clientes. También es posible que ocurra una manifestación de falla de lentitud en el rendimiento, que puede atribuirse a varios motivos, entre ellos la sobrecarga del servidor, el bloqueo de procesos, el agotamiento de recursos computacionales o la congestión de la red.
Dado a relevância do tema, foi realizado um estudo de caso com o objetivo de elaborar um projeto de gerenciamento de risco para o site de um instituto de educação. A pesquisa avaliou como era feito o gerenciamento de risco e qual a percepção dos membros da equipe de desenvolvimento sobre a importância desse gerenciamento. Depois do diagnóstico, foram listados os principais riscos aos quais os sites estão expostos e, particularmente, o site em estudo. Ao final foi elaborado um plano de respostas aos riscos.
El estudio[8] fue elaborado en un instituto brasileño de educación e investigación, con sede en el interior de São Paulo y más de 500 colaboradores. Entre los servicios ofrecidos se encontraban cursos de grado y posgrado, análisis técnicos —principalmente para el sector de agronegocios—, capacitaciones de gestión, entre otros. El sitio web elegido para el estudio formaba parte del portafolio de productos ofrecidos por el instituto y divulgaba en su página cursos de posgrado en la modalidad de enseñanza a distancia (EaD).
Este sitio fue seleccionado como objetivo del estudio en función de su alta demanda de visitantes. Más del 70% de todo el tráfico se originaba de anuncios pagados, lo que hacía crítica la necesidad de un sitio de alta disponibilidad. Al ser dirigido a la página, el visitante encontraba información sobre la institución y sobre cada curso; sin embargo, para inscribirse en uno de ellos, el usuario era dirigido a otro sistema, que recopilaba datos personales y de pago.
Un equipo de desarrollo interno era responsable de desarrollar nuevas funcionalidades, actualizar y mantener el sitio web. Este equipo contaba con profesionales de producto, experiencia de usuario, diseñadores, desarrolladores y analistas de datos. La identificación de los riesgos se delimitó al sitio web objeto de estudio, no incluyéndose el sistema responsable de registro y pago, ni acciones de marketing para captación de leads (clientes potenciales). Los riesgos identificados se referían a fallos que, de ocurrir, podrían generar tiempo de inactividad.
La metodología utilizada en la presente investigación fue el estudio de caso, que tiene como estrategia examinar acontecimientos contemporáneos con técnicas utilizadas en investigaciones históricas, pero añadiendo como fuentes de evidencia la observación directa y la serie sistemática de entrevistas[9]. En la primera etapa se mapearon las características técnicas del sitio en estudio, con el propósito de comprender la relación entre el panorama vigente en la época y el nivel de percepción de riesgo de los evaluadores en lo que respecta a las amenazas más comunes en proyectos de sitios. Para auxiliar en el diagnóstico, se utilizó la lista de riesgos comunes del “Project Management Body of Knowledge” (PMBOK)[1], que contiene ítems, acciones y puntos a ser considerados, basándose en información histórica y conocimiento acumulado de proyectos similares. A partir del resultado, se realizaron entrevistas con miembros del equipo y con especialistas para la cualificación de los riesgos, evaluando las probabilidades y el impacto en caso de ocurrencia.
Salles Jr. et al.[8] describen que el análisis probabilístico de eventos generalmente se hace necesario cuando falta información sobre el proceso, lo que puede generar imprecisiones. Por ello, cuanta más información se obtenga, menos incierto será el evento. De esta manera, tras la identificación de los riesgos comunes del objeto de este estudio, se realizó una entrevista, mediante la aplicación de un cuestionario, a miembros del equipo del proyecto. El resultado fue un plan de respuestas a los riesgos, proponiendo alternativas para prevenir o reducir la exposición del negocio a amenazas.
Durante el ciclo de vida de un proyecto, los riesgos continúan surgiendo y los procesos de gestión deben ocurrir de forma interactiva; el equipo involucrado en el proyecto necesita entender si el nivel de exposición al riesgo es aceptable y, para ello, deben considerarse el tamaño, la complejidad y la importancia estratégica del proyecto[2].
El sitio objeto del estudio utilizaba una plataforma en la nube especializada en la tecnología y el lenguaje de programación para los que fue desarrollado. Esta plataforma utilizaba variables de entorno de forma segura, evitando que información sensible quedara expuesta en el código fuente o transitara por otro medio. Las variables de entorno son estructuras importantes con valores dinámicos que se almacenan de forma temporal en el servidor y se utilizan durante la ejecución de un programa; dan soporte a un proceso de integración y entrega continua, que automatiza y facilita la implementación de nuevas actualizaciones y garantiza que la última versión funcional permanezca disponible en caso de que se detecte algún error, disminuyendo las posibilidades de un probable fallo en el sitio[10].
Entre los principales recursos ofrecidos por la plataforma se encontraban: soporte para navegación segura a través del “protocolo de transferencia de hipertexto seguro (HTTPS)” — que funciona como una protección para la comunicación y la transferencia de datos entre el navegador web y un sitio web[11] — y del certificado de seguridad “protocolo seguro de capa de transporte (SSL)”, un protocolo que exige que el servidor web tenga un certificado digital, funcionando como una clave pública para la transferencia de datos a través de esta conexión[12]. La plataforma también ofrecía recursos de mitigación de ataques de denegación de servicio distribuido, comúnmente llamado ataque “denegación de servicio distribuido (DDoS)”. El ataque de DDoS utiliza miles de máquinas infectadas para acceder simultáneamente a un sitio web, causando una sobrecarga en el sistema y, en consecuencia, la denegación del servicio por parte del servidor[13].
La actualización del código fuente se realizaba íntegramente mediante procesos de control de versiones de código, lo que permite obtener un historial fiable de las modificaciones y facilita la restauración de una versión anterior en caso de que ocurra un problema. El acceso al repositorio del código fuente estaba restringido a los miembros del equipo de desarrollo del proyecto.
Según Sutherland[14], la definición de hecho en la metodología ágil significa que se cumplieron todas las condiciones y criterios establecidos por el equipo, y se realizaron las pruebas. El equipo del sitio en cuestión utilizaba como definición de hecho para todas las demandas de actualización los siguientes criterios: 1) el incremento deberá pasar por pruebas funcionales, y el probador no deberá ser el mismo que creó el incremento; 2) el incremento deberá pasar por revisión de al menos otro par y ser liberado solo después de aprobación; 3) deben tenerse en cuenta en la creación/desarrollo los criterios no funcionales de accesibilidad, rendimiento y seguridad; 4) se debe documentar lo que se hizo; 5) los criterios de aceptación deberán ser atendidos; 6) el incremento deberá estar alineado a las directrices de experiencia del usuario “user experience” (UX) y “user interface” (UI).
La Tabla 1 presenta un estudio de incidentes comunes que pueden ocasionar interrupciones en sitios web, basándose en el historial de ocurrencias reales sufridas en diversas páginas[5],[15]. Existen otros riesgos genéricos y comunes que pueden causar la indisponibilidad o afectar la integridad de un sitio web; sin embargo, para este estudio, se consideraron solo los riesgos a los que se creía que el sitio estudiado podría estar expuesto. Cada riesgo contiene un identificador propio y la respectiva descripción.
Tabla 1. Riesgos identificados
| ID | Riesgo |
| 1 | Agotamiento de recursos: fuga de memoria, procesos con uso intensivo de recursos, que hacen que las solicitudes de página alcancen el tiempo de espera, espacio en disco insuficiente |
| 2 | Factores ambientales: caída de energía, desastres naturales |
| 3 | Sobrecarga de tráfico: ocurre principalmente cuando hay un flujo anormal de visitantes en el sitio web, ya sea por alguna campaña publicitaria, ya sea por un posible ataque cibernético |
| 4 | Intentos de ataques o malwares: ataques DDoS, por ejemplo, pueden llevar a una alta demanda de tráfico en el sitio de forma malintencionada, para que quede indisponible |
| 5 | Error de codificación: en el área de la tecnología, un bug es un error de codificación en un programa de computadora[10]. Desafortunadamente, no siempre un bug puede ser detectado de forma rápida |
Durante el análisis cualitativo se evalúan las probabilidades e impactos, lo que ayuda a priorizar los riesgos. Una vez identificados los riesgos, es posible calificarlos, asignando puntuaciones a la probabilidad y al impacto de cada evento[9]. Las Tablas 2 y 3, a continuación, muestran la clasificación de probabilidad y el nivel de impacto determinados para el sitio estudiado.
Tabla 2. Clasificación de la probabilidad de ocurrencia
| Escala de probabilidad | Grado de probabilidad de ocurrencia |
| 0,1 | Muy rara la posibilidad de ocurrencia |
| 0,3 | Baja probabilidad de ocurrencia |
| 0,5 | Probabilidad moderada de ocurrencia |
| 0,7 | Alta probabilidad de ocurrencia |
| 0,9 | Muy alta la probabilidad de ocurrencia |
Tabla 3. Clasificación del impacto del evento de riesgo
| Escala de probabilidad | Grado de impacto |
| 0,1 | Muy bajo |
| 0,3 | Bajo |
| 0,5 | Contenido |
| 0,7 | Elevado |
| 0,9 | Muy alto |
Los impactos se dividieron en tres categorías:
- costo: impacto financiero generado para la empresa en caso de que ocurriera el evento de riesgo (por ejemplo, la pérdida de leads si hubiera una indisponibilidad en el servicio que perjudicara o impidiera el registro);
- estratégico: hecho que pudiera impactar el desempeño de una campaña o acción de marketing o perjudicar la imagen de la marca;
- calidad: hecho que causara una experiencia negativa para el usuario, como lentitud, fallo de funcionalidad, problemas de navegación o página no encontrada.
Tras identificar los principales riesgos comunes a los que estaba expuesto el sitio web, se realizó una entrevista mediante cuestionario a miembros del equipo, con siete encuestados, de los cuales uno era gestor de producto y seis desarrolladores. Cada encuestado asignó un valor aleatorio a los riesgos identificados, siguiendo la escala probabilística de 0,1 a 0,9 para la clasificación de la probabilidad de ocurrencia y el nivel de impacto del evento de riesgo, de acuerdo con las Tablas 2 y 3, respectivamente.
La Tabla 4 presenta los riesgos priorizados por el grupo conforme al mayor grado de riesgo calculado (columna “riesgo”), el cual fue obtenido a partir de la multiplicación de la probabilidad de ocurrencia (columna “probabilidad”) por el riesgo consolidado (columna “consolidado”), siendo este proveniente del mayor valor atribuido como impacto entre las tres categorías (costo, estratégico y calidad).
Tabla 4. Matriz de probabilidad de riesgo
| ID | Evento de riesgo | Probabilidad | Repercusión | Integrado | Riesgo | ||
| Costo | Estratégico | Calidad | |||||
| 1 | Agotamiento de recursos | 0,30 | 0,58 | 0,72 | 0,70 | 0,72 | 0,21 |
| 2 | Factores ambientales | 0,21 | 0,64 | 0,58 | 0,64 | 0,64 | 0,13 |
| 3 | Sobrecarga de tráfico | 0,50 | 0,61 | 0,67 | 0,67 | 0,67 | 0,33 |
| 4 | Intentos de ataques o malwares | 0,47 | 0,67 | 0,70 | 0,72 | 0,72 | 0,34 |
| 5 | Error de codificación | 0,55 | 0,50 | 0,50 | 0,55 | 0,55 | 0,31 |
| Riesgo general | 1,34 | ||||||
El riesgo general del proyecto se normalizó según lo recomendado por Salles Jr. et al.[8], según la Ecuación 1:
 | (1) |
donde, RGP: es el riesgo general del proyecto; P: son las probabilidades; I: son los impactos; n: es la cantidad de riesgos identificados (en este caso, igual a 5); EP: la escala de probabilidades; y EI: la escala de impacto, ambos con valores de 0,9.
Como resultado de la normalización en el ámbito de este estudio, se obtuvo un riesgo general del 33%. La percepción de riesgo elevada se debió a la sensibilidad del proyecto, reforzando la relevancia del estudio del tema y la necesidad de la elaboración de un proyecto de gestión de riesgos con planes de respuesta adecuados para cada eventualidad.
El gráfico a continuación, representado por la Figura 1, presenta la matriz de riesgo para cada evento de riesgo identificado. Ayuda a comprender el grado de percepción sobre la probabilidad de que ocurra cada evento y sobre su impacto, en caso de que ocurra. La matriz también ayuda a priorizar los riesgos de una manera más coherente, evitando el uso de suposiciones.
Figura 1. Matriz de riesgo
Fuente: Adaptado de Salles Jr. et al.[8]
El plan de respuesta a los riesgos tiene como objetivo ayudar al equipo involucrado en el proyecto a prever estrategias y acciones que deben ejecutarse para responder a las amenazas identificadas durante el proceso de identificación de riesgos[8].
Con base en el análisis de riesgos realizado en el estudio, se elaboró un proyecto de gestión de riesgos para ayudar en la creación de un plan de respuesta, con los objetivos de: ofrecer directrices para la adopción de buenas prácticas de desarrollo y revisión de códigos; describir posibles problemas de seguridad; orientar sobre la planificación del servidor más apropiado para el sitio web; y recomendar medidas de mitigación de riesgos.
Los errores o bugs pueden ser causados por la ausencia o ineficiencia en los procesos de revisión de código, fallos o falta de políticas de seguridad para la implementación, o por la ausencia de buenas prácticas durante el desarrollo. Como respuesta, es necesario que el equipo de desarrollo implemente procesos de revisión de código en cada nueva actualización o mantenimiento del proyecto.
En una revisión deben observarse múltiples aspectos, como el funcionamiento del código, la claridad de su escritura, la presencia de comentarios útiles, entre otros factores. Además, el proceso de revisión de código puede y debe ser utilizado como parte del proceso de mejora y aprendizaje del equipo de desarrollo[16].
Se recomienda que el equipo involucrado en el proyecto continúe utilizando el sistema de control de versiones (SCV). La adopción de esta práctica permite que con cada modificación se obtenga un historial de versiones anteriores, funcionando como una copia de seguridad que puede ser restaurada en caso de que surja algún problema en una nueva versión, generando así un historial de los cambios en el proyecto a lo largo de su ciclo de vida y facilitando el trabajo colaborativo entre los desarrolladores en un mismo proyecto[17].
Los sitios web son constantemente susceptibles a ciberataques. Entre los principales tipos se encuentran: ataque DDoS; “man-in-the-middle (MitM)”; “phishing”; “spear phishing”; “drive-by”; fuerza bruta; “SQL injection”; “malware”; y “cross-site scripting attack (XSS)”. La Tabla 5 detalla cada tipo de ataque.
Tabla 5. Tipos comunes de ataques cibernéticos en sitios web
| Nombre | Descripción |
| Ataque de fuerza bruta | En este método de ataque, los hackers utilizan algoritmos que realizan miles de combinaciones para descubrir el inicio de sesión y la contraseña |
| “De pasada” | Método utilizado para la difusión de “malware”; en este tipo de ataque, los hackers buscan sitios inseguros e inyectan “scripts” (códigos) maliciosos en el protocolo HTTP, por ejemplo |
| “Software malicioso” | También conocido como software malicioso, es un programa o archivo intencionalmente perjudicial para el dispositivo |
| “MitM” | Abreviatura del inglés para “man-in-the-middle”. En este tipo de ataque, el invasor se inserta entre la comunicación de un cliente y un servidor. Son ejemplos el secuestro de sesión y la suplantación de IP |
| “Phishing” y “spear phishing” | Es la modalidad de ataque utilizada para enviar correos electrónicos haciéndose pasar por fuentes confiables, con el objetivo de obtener información privilegiada o influenciar al usuario a realizar alguna acción; otra técnica utilizada por los estafadores es la clonación de sitios web legítimos con la intención de obtener información personal o credenciales de acceso al sitio web verdadero |
| “Inyección SQL” | Término en inglés para inyección de “structured query language (SQL)”. Lenguaje utilizado en bases de datos, es un tipo de ataque común en el cual se insertan comandos SQL, que pueden desde capturar, insertar, modificar o eliminar información de clientes de la base de datos |
| “Cross-site scripting (XSS)” | Es un tipo de ataque utilizado principalmente para explotar vulnerabilidades que permiten que, mientras la víctima navega por el sitio web, el hacker capture información almacenada en el navegador, capturas de pantalla, pulsaciones de teclas, información de red o incluso controle la máquina de la víctima |
Protegerse de estos y otros ataques requiere comprender el concepto de ofensiva. Para Melnick[13], las medidas destinadas a mitigar las amenazas pueden variar, pero existen tratativas básicas sobre cómo mantener actualizados los sistemas y bases de datos de virus, una buena capacitación del equipo, la configuración correcta del “firewall”, contraseñas seguras y copias de seguridad regulares. Es importante que el sitio cuente con un certificado de seguridad, incluso cuando no maneje información confidencial. La navegación a través del protocolo HTTPS, además de proteger contra el uso indebido del sitio, es un requisito obligatorio para muchos recursos de tecnología[18].
Las indisponibilidades del servidor pueden ocurrir tanto por la ausencia de mantenimiento como por defectos inesperados. Es importante la elección de un servicio de calidad reconocida, como la red de entrega de contenido, del inglés “content delivery network (CDN)”, que, según Plesky[6], puede ser un recurso adoptado para crear una capa entre el servidor en el que está alojado el sitio web y el usuario. El servicio posibilita la entrega de contenido por medio de servidores distribuidos geográficamente, utilizando sistemas de caché de contenido, lo que evita la indisponibilidad del sitio web cuando el servidor esté indisponible por un corto período. La CDN también ayuda a impedir que “bots” (robots) maliciosos accedan al sitio web, filtrando el tráfico y evitando sobrecarga en el servidor.
La plataforma de alojamiento del sitio web estudiado ofrecía por defecto el servicio de CDN activo, sin necesidad de configuración o contratación adicional. Plesky[6] destaca que la expiración del dominio también puede causar la indisponibilidad del sitio web. El autor recomienda, por ello, la compra por largos períodos o la renovación automática, como en el caso del dominio del sitio web en estudio.
El tiempo de inactividad también puede ser planificado para operaciones normales de infraestructura de tecnología de la información (TI), como copias de seguridad, actividades de mantenimiento o correcciones de sistema. Sin embargo, la inactividad planificada es uno de los principales factores causantes de incidentes, como, por ejemplo, cuando una copia de seguridad tarda más de lo planeado[5].
La plataforma en la nube del sitio objeto de esta investigación tenía un “uptime” (tiempo en que el servidor está operacionalmente disponible[11]) del 99,99%, garantizado por la empresa proveedora. La plataforma también contaba con una página para la verificación del estado de los servicios y canales de soporte para reportar incidencias de fallos.
Fue posible percibir, a través de este trabajo, que la plataforma estudiada tenía un servicio adecuado al tamaño del proyecto; aun así, sería recomendable que evaluara una segunda opción de implementación rápida en un alojamiento alternativo, en caso de factores ambientales que puedan indisponer el sitio web por largos períodos. Tener un plan de respuesta a los riesgos no garantiza que el sitio web quede completamente seguro, pero ayuda al equipo a pensar proactivamente en procesos de mejora continua.
Como recomendación para complementar este estudio, se sugiere la realización de auditorías periódicas de seguridad en el sitio web, para encontrar posibles vulnerabilidades y mitigar la posibilidad de ataques cibernéticos. Se concluyó que, para el sitio web estudiado, la probabilidad de ocurrencia de los eventos listados era baja, principalmente debido a las acciones de mitigación que ya eran adoptadas por el equipo de desarrollo; los impactos, sin embargo, pueden ser altos en caso de que lleguen a ocurrir.
Referencias
[1] Instituto de Gerenciamento de Projetos (PMI). 2021. O padrão para gerenciamento de projetos e um guia para o corpo de conhecimento em gerenciamento de projetos (guia PMBOK). 7ed. Project Management Institute, Newtown Square, PA, EUA.
[2]Project Management Institute (PMI). 2017. Um guia do conhecimento em gerenciamento de projetos. 6ed. Project Management Institute, Newtown Square, PA, EUA.
[3] Empresa Brasil de Comunicação (EBC). 2020. Mais da metade das empresas brasileiras usam internet para vender e 78% estão nas redes sociais. Disponível em: <https://agenciabrasil.ebc.com.br/radioagencia-nacional/acervo/economia/audio/2020-04/mais-da-metade-das-empresas-brasileiras-usam-internet-para-vender-e-78-estao/>. Acesso em: 10 abr. 2022.
[4] Pagely. 2015. Risk Mitigation and the True Cost of Website Downtime. Disponível em: <https://pagely.com/blog/risk-mitigation-and-the-true-cost-of-website-downtime/>. Acesso em: 10 abr. 2022.
[5] Pertet S.; Narasimhan P. 2005. Causes of Failure in Web Applications. Technical Report, Parallel Data Laboratory, Carnegie Mellon University, Pittsburg, PA, EUA.
[6] Plesky E. 2021. What is Website Downtime and Why Should You Take it Seriously? Disponível em: <https://www.plesk.com/blog/various/what-is-website-downtime-and-why-should-you-take-it-seriously/>. Acesso em: 10 abr. 2022.
[7] G1. Tecnologia. Sites de Americanas e Submarino voltam a funcionar após três dias fora do ar. 2022. Disponível em: <https://g1.globo.com/tecnologia/noticia/2022/02/23/americanas-tem-site-reestabelecido-depois-de-quatro-dias-fora-do-ar.ghtml>. Acesso em: 10 abr. 2022.
[8] Salles Jr. C.A.C.; Soler A.M.; Valle J.A.S.; Rabechini Jr. R. 2006. Gerenciamento de riscos em projetos. FGV Editora, Rio de Janeiro, RJ, Brasil.
[9] Yin R.K. 2001. Estudo de caso: Planejamento e métodos. 2ed. Bookman, Porto Alegre, RS, Brasil.
[10] Oliveira M.E.; Zuccherelli M.F.L.; Libera G.P.D.; Oliveira R.L.Z.; Tech A.R.B. 2020. Introdução à robótica educacional com Arduíno – hands on!: iniciante. Faculdade de Zootecnia e Engenharia de Alimentos (FZEA/USP), Pirassununga, SP, Brasil. DOI: 10.11606/9786587023052.
[11] Tech Target. 2022. Computer Glossary, Computer Terms – Technology Definitions and Cheat Sheets from WhatIs.com – The Tech Dictionary and IT Encyclopedia. Disponível em: <https://www.techtarget.com/whatis>. Acesso em: 13 set. 2022.
[12] Bhiogade, M.S. 2001. Secure Socket Layer. In: Anais do Computer Science and Information Technology Education Conference; 2002; Cork, Irlanda. p. 85-90. DOI: 10.2139/ssrn.291499.
[13] Melnick J. 2018. Top 10 Most Common Types of Cyber Attacks. Disponível em: <https://blog.netwrix.com/2018/05/15/top-10-most-common-types-of-cyber-attacks/>. Acesso em: 25 jul. 2022.
[14] Sutherland J. 2014. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. LeYa, São Paulo, SP, Brasil.
[15] Jackson B. 2022. Website Downtime: Applicable Tips on How to Prevent It. Disponível em: <https://kinsta.com/blog/website-downtime/>. Acesso em: 24 set. 2022.
[16] Google. [s.d.]. Google Engineering Practices Documentation. Disponível em: <https://google.github.io/eng-practices/>. Acesso em: 28 jul. 2022.
[17] Zolkifli N.N.; Ngah A.; Deraman A. 2018. Version Control System: A Review. Procedia Computer Science 135: 408-415. DOI: 10.1016/j.procs.2018.08.191.
[18] Basques K. 2020. Por que HTTPS é importante. Disponível em: <https://web.dev/why-https-matters/>. Acesso em: 29 jul. 2022.
Como citar
Gonzaga F.L.; Bigaton A. Gerenciamento de risco para site de instituto de educação. Revista E&S. 2023; 4: e20230069.
Sobre os autores
Fabio Luis Gonzaga, Instituto de Pesquisa e Educação Continuada em Economia e Gestão de Empresas – Pecege – Tecnologia da Informação – R. Cezira Giovanoni Moretti, 580 – Santa Rosa – CEP 13414-157 – Piracicaba/SP, Brasil.
Aline Bigaton
, Professora orientadora, Pecege – R. Cezira Giovanoni Moretti, 580 – Santa Rosa – CEP 13414-157 – Piracicaba/SP, Brasil.
Enlace de descarga: PDF