Realiza un resumen sobre los artículos descritos en los recursos 7 y 8.

Una estrategia para la gestión de errores y la prevención de la pérdida de información

confidencial implica una comprensión integral de la ubicación de los datos y la evaluación
de los riesgos involucrados. A pesar de que los ciberdelincuentes tienden a captar la
atención en casos destacados de robo de datos en grandes corporaciones, la mayoría de las
ocasiones en que se produce la pérdida de información ocurre en empresas de menor
tamaño, en especial debido a la falta de una gestión adecuada de sus datos confidenciales.
En realidad, las pérdidas de información rara vez tienen relación con actividades de
ciberdelincuencia.
¿En qué radica la gestión de errores y la prevención de la pérdida de datos? Este
enfoque engloba una estrategia integral que involucra a individuos, procesos y tecnología,
concentrándose en la identificación de la ubicación de los datos, su clasificación y la
implementación de medidas para garantizar su seguridad y resguardo.
1. La mayoría de las organizaciones incorporan siete etapas en sus prácticas
recomendadas para la gestión de errores y la prevención de la pérdida de datos:
2. Definir lo que la organización considera como información confidencial.
3. Localizar los datos y determinar quiénes tienen acceso a ellos.
4. Clasificar los datos según su importancia y el potencial daño que su pérdida podría
causar a la organización, ya sea por error o robo.
5. Identificar a quién pertenecen los datos.
6. Establecer responsabilidades claras para los propietarios de los datos.
7. Evaluar si los datos son necesarios o si se han vuelto obsoletos y representan un
riesgo innecesario.
8. Eliminar los datos en cuanto ya no sean requeridos o protegerlos si es necesario que
permanezcan.
Las consecuencias de no llevar a cabo una sólida gestión de errores y pérdida de datos
pueden ser diversas:
- Incremento en las primas de seguros e incluso posibles sanciones legales.
- Disminución en las ventas en caso de que los datos perdidos afecten la capacidad de
producción, ventas, atención al cliente o la imagen de la marca.
- Aumento de los costos de tecnología de la información y de ineficiencia en general.
Las empresas deben mejorar su enfoque en la gestión de errores y la prevención de la
pérdida de datos sensibles. Para lograrlo, es fundamental:
- Evitar acumular más datos de los necesarios.
- Considerar las principales causas que podrían conducir a la pérdida de datos o
errores en su manejo.
- Adoptar las medidas y precauciones adecuadas para prevenir tales situaciones.
Asegurar la integridad y seguridad de tus datos implica considerar algunas prácticas
fundamentales:
Además de estas recomendaciones, considera lo siguiente:
- Mantén tus dispositivos limpios y libres de polvo.
- Si un ordenador se calienta demasiado, es conveniente desmontarlo y limpiarlo.
- Guarda tus copias de seguridad en varias ubicaciones.
- Si percibes que un disco duro está a punto de fallar, crea una imagen completa del
disco, incluyendo el sistema operativo
La correcta gestión de errores y excepciones es fundamental para el funcionamiento
adecuado del intermediario. Debes considerar cuándo y cómo la extensión definida por
el usuario debe manejar estas situaciones.
El manejo de errores y excepciones mencionado en este contexto se refiere a aspectos a
considerar al desarrollar extensiones definidas por el usuario para IBM Integration Bus
utilizando el lenguaje de programación C. Si estás desarrollando extensiones en Java,
puedes emplear los métodos estándar de manejo de errores y excepciones de Java. Si el
intermediario genera una excepción internamente, está disponible una excepción Java
de la clase MbException.
El intermediario genera excepciones de C++ para tratar condiciones de error. Estas
excepciones se identifican en las capas pertinentes del software del intermediario y se
manejan en consecuencia. Sin embargo, los programas escritos en C no pueden detectar
excepciones de C++, y todas las excepciones generadas pasan por alto, por defecto, el
código de las extensiones definidas por el usuario en C, siendo detectadas en capas
superiores del intermediario.
Conforme a la convención, las funciones de utilidad generalmente emplean el valor de
retorno para proporcionar los datos solicitados, como la dirección o el manejador de un
objeto de intermediario. Ocasionalmente, el valor de retorno señala la ocurrencia de un
error. Por ejemplo, si la dirección o el manejador de un objeto de intermediario no
pueden ser recuperados, se devuelve el valor cero (CCI_NULL_ADDR).
Adicionalmente, los detalles de un error se almacenan en el parámetro de salida del
código de retorno, el cual es parte integral del prototipo de función de utilidad. Si la
 función de utilidad se completa sin problemas y el valor de returnCode no está vacío,
contendrá CCI_SUCCESS. En caso contrario, contendrá uno de los códigos de retorno
enumerados aquí. Evaluar el valor de returnCode permite determinar si la función de
utilidad fue ejecutada con éxito.
Si una llamada a una función de utilidad provoca que el intermediario genere una
excepción, el error solo será visible para la extensión definida por el usuario si se
proporciona un valor para el parámetro returnCode correspondiente a esa función. Si se
asigna un valor nulo a returnCode y surge una excepción:
- La extensión definida por el usuario no identifica la excepción.
- La función de utilidad no regresa a la extensión definida por el usuario.
- El control de la ejecución se traslada a capas superiores del intermediario para
procesar la excepción.
Por lo tanto, una extensión definida por el usuario no puede llevar a cabo su propia
recuperación de errores. Sin embargo, al especificar el parámetro returnCode y producirse
una excepción, se devuelve un código de retorno de CCI_EXCEPTION. En este escenario,
es posible utilizar cciGetLastExceptionData o cciGetLastExceptionDataW (siendo esta
última capaz de manejar texto de rastreo Unicode) para obtener información diagnóstica
acerca del tipo de excepción que ocurrió. Los detalles se obtienen de las estructuras
CCI_EXCEPTION_ST o CCI_EXCEPTION_WIDE_ST.
Si no hay recursos que necesiten liberación, es recomendable no establecer el argumento
returnCode en la extensión definida por el usuario. Al omitir este argumento, las
excepciones pueden ser manejadas por el intermediario sin involucrar a las extensiones
definidas por el usuario. En tales casos, el intermediario se encargará de gestionar estas
excepciones en niveles superiores de la pila del IBM Integration Bus.
Es posible retornar mensajes insertados en los miembros CCI_STRING_ST de la estructura
CCI_EXCEPTION_ST. El uso de CCI_STRING_ST permite a la extensión definida por el
usuario almacenar temporalmente todas las inserciones necesarias. El intermediario copiará
los datos en este espacio intermedio y proporcionará la cantidad de bytes de salida y la
longitud real de los datos. Si el espacio intermedio resulta insuficiente, no se realizará
ninguna copia de datos. En ese caso, el miembro "dataLength" se puede ajustar para
aumentar el tamaño del espacio, si es necesario.
La extensión definida por el usuario puede establecer un valor no nulo para returnCode y
aplicar su propia recuperación de errores si es requerido. Las llamadas a la función de
referencia relacionada, como cciGetLastExceptionData, cciLog, cciRethrowLastException,
cciThrowException, cciGetLastExceptionDataW, cciLogW y cciThrowExceptionW,
pueden proporcionar información adicional y opciones para el manejo de excepciones.
Tipos de Excepciones y Comportamiento del Intermediario
El intermediario genera una serie de excepciones que pueden ser transmitidas a una
extensión definida por el usuario. Estas excepciones también pueden ser generadas por una
extensión definida por el usuario cuando se encuentra en una situación de error. Estas son
las clases de excepciones:
- Excepciones Fatales: Se generan cuando se presenta una condición que impide que
el proceso del intermediario continúe su ejecución de manera segura o cuando la
política del intermediario requiere la terminación del proceso. Ejemplos de
excepciones fatales incluyen la incapacidad de adquirir un recurso crítico del
sistema o un error grave de software detectado internamente. En caso de una
excepción fatal, el proceso del intermediario finaliza.
- Excepciones Recuperables: Estas excepciones se generan para errores que, aunque
no son terminales por naturaleza, indican que el flujo de mensajes actual debe ser
finalizado. Por ejemplo, las excepciones recuperables pueden derivar de datos
inválidos en el contenido de un mensaje o de un error en la grabación de un mensaje
en un nodo de salida. Cuando se produce una excepción recuperable, el proceso del
mensaje actual se interrumpe en dicho punto, pero se reanuda ejecutando el flujo
desde el nodo de entrada correspondiente.
- Excepciones de Configuración: Se generan cuando una solicitud de configuración
falla. Esto puede deberse a un error en el formato de la solicitud o a datos
incorrectos. Una excepción de configuración resulta en el rechazo de la solicitud y
en la emisión de un mensaje de respuesta de error.
- Excepciones del Analizador: Los analizadores de mensajes generan estas
excepciones cuando se presentan errores que impiden analizar el contenido del
mensaje o crear una corriente de bits. El intermediario maneja una excepción del
analizador como una excepción recuperable.
- Excepciones de Conversión: Estas excepciones son generadas por las funciones de
conversión de caracteres del intermediario cuando se encuentran con datos no
válidos al intentar convertirlos a otro tipo de información. El intermediario trata una
excepción de conversión como una excepción recuperable.
- Excepciones de Usuario: Estas excepciones se generan cuando un nodo "Throw"
provoca una excepción definida por el usuario.
- Excepciones de Base de Datos: Estas excepciones se generan cuando un sistema de
gestión de bases de datos reporta un error durante la operación del intermediario. El
intermediario maneja una excepción de base de datos como una excepción
recuperable.