Cargar ticket
Reportá un incidente o requerimiento con detalle, impacto, usuario afectado y adjuntos si corresponde.
Soporte técnico
Cargá tickets, consultá solicitudes existentes y accedé a información pública de ayuda para incidentes o requerimientos operativos.
Cargar ticket
Contanos qué necesitás resolver.
Completá el formulario con el mayor detalle posible. El ticket queda registrado en Helpdesk para seguimiento del equipo técnico.
Accesos rápidos
Tickets, portal y base de conocimientos.
Centralizamos los accesos principales para que puedas cargar solicitudes, dar seguimiento y consultar información pública disponible.
Mis tickets
Ingresá al portal para revisar solicitudes, respuestas y estado de seguimiento de casos anteriores.
Base de conocimientos
Consultá artículos públicos del módulo Información y contenido disponible del Helpdesk.
Base de conocimientos
Artículos de ayuda publicados.
Consultá guías y procedimientos públicos sin salir de Soporte. Si no encontrás lo que necesitás, cargá un ticket y el equipo técnico lo revisa.
Qué es un departamento IT externo y cuándo una empresa lo necesita
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Ayudar a responsables de empresas a evaluar si necesitan una función IT estable, aunque no resulte conveniente incorporar un equipo interno completo.
Contexto
Un departamento IT externo es un equipo que asume de manera continua responsabilidades de soporte, infraestructura, seguridad, documentación y planificación. No equivale a llamar a un técnico cuando algo falla: trabaja con prioridades, responsables, registros y revisiones periódicas.
Suele ser útil en empresas que dependen de la tecnología para operar pero no cuentan con especialistas internos suficientes. El alcance puede incluir mesa de ayuda, administración de Microsoft 365, redes, servidores, backups, proveedores y proyectos, siempre con límites y responsables acordados.
Puntos clave
- Existe un canal único para incidentes y solicitudes, con seguimiento y responsables.
- La infraestructura y los accesos se relevan y documentan antes de proponer cambios.
- Las tareas preventivas y el monitoreo reducen la dependencia del soporte reactivo.
- Las decisiones se priorizan según impacto operativo, riesgo y costo total.
- La empresa conserva visibilidad sobre activos, proveedores, credenciales institucionales y documentación.
Recomendaciones
- Identificar sistemas críticos, sedes, usuarios y horarios que condicionan la operación.
- Definir qué responsabilidades permanecerán dentro de la empresa y cuáles se delegarán.
- Acordar canales, prioridades, escalamiento, niveles de servicio y responsables de autorización.
- Realizar un relevamiento inicial y construir un plan de normalización por etapas.
- Revisar mensualmente incidentes, capacidad, seguridad, proyectos y riesgos pendientes.
Riesgos y advertencias
- Delegar sin conservar propiedad de dominios, contratos, documentación y cuentas institucionales genera dependencia.
- Contratar solo horas reactivas no reemplaza una función IT organizada.
- Un alcance ambiguo provoca expectativas distintas sobre tiempos, cobertura y responsabilidades.
Cómo validar el resultado
- Cada solicitud tiene un canal, una prioridad y un estado visible.
- Existe un inventario básico y una lista de servicios críticos con responsables.
- La dirección recibe información periódica sobre riesgos, capacidad y mejoras.
Buenas prácticas
El servicio debe comenzar con información verificable y un plan gradual. Conviene acordar indicadores simples, reuniones de revisión y un mecanismo de salida que asegure la entrega ordenada de documentación.
Próximos pasos
Si hoy la información está dispersa, un relevamiento inicial permite dimensionar usuarios, activos, dependencias, riesgos y prioridades antes de definir el alcance de un departamento IT externo.
Qué es el monitoreo de infraestructura
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Explicar qué debe monitorearse, cómo convertir datos en alertas útiles y qué operación humana necesita una plataforma de monitoreo.
Contexto
Monitorear infraestructura significa recopilar y evaluar estados y métricas de servidores, redes, almacenamiento, servicios y aplicaciones. Permite detectar indisponibilidad, degradación, capacidad insuficiente y comportamientos fuera de lo esperado.
Una herramienta no resuelve por sí sola los incidentes. Cada alerta necesita propósito, umbral, severidad, responsable, horario y acción. Sin mantenimiento, el monitoreo acumula activos retirados y avisos que nadie atiende.
Puntos clave
- Disponibilidad confirma si un servicio responde; rendimiento muestra cómo responde.
- Capacidad observa tendencias de disco, memoria, enlaces y otros recursos finitos.
- Las métricas deben relacionarse con servicios y usuarios afectados.
- Umbrales estáticos, dinámicos y por tiempo requieren contexto y ajuste.
- Eventos, logs y auditoría complementan métricas, pero no son equivalentes.
Recomendaciones
- Inventariar servicios críticos, dependencias y responsables.
- Definir pocas comprobaciones que detecten fallas reales y riesgos próximos.
- Asignar severidades y rutas de escalamiento con horarios claros.
- Crear paneles orientados a operación, capacidad y revisión de negocio.
- Revisar falsos positivos, alertas repetidas y activos sin datos.
Riesgos y advertencias
- Alertar por todo genera fatiga y reduce la atención a eventos importantes.
- Monitorear solo que el servidor responde puede ocultar una aplicación inutilizable.
- Exponer agentes o consolas sin controles adecuados aumenta superficie de ataque.
Cómo validar el resultado
- Simulaciones controladas generan la alerta y el escalamiento esperados.
- Cada alerta crítica tiene procedimiento inicial o responsable técnico.
- Los reportes muestran tendencias que permiten tomar decisiones de capacidad.
Buenas prácticas
Comenzar por servicios críticos y mejorar por iteraciones. Medir utilidad de alertas, documentar mantenimiento y conservar historial suficiente para comparar tendencias.
Próximos pasos
Un relevamiento permite construir una matriz de monitoreo con activo, métrica, umbral, severidad, responsable y acción antes de instalar o ampliar herramientas.
Procedimiento de alta de un nuevo empleado
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Asegurar que cada incorporación reciba a tiempo solo los accesos y recursos autorizados, con responsables, evidencia y una experiencia de inicio ordenada.
Contexto
El alta comienza antes del primer día y requiere coordinación entre responsable del área, administración, recursos humanos, IT y, en algunos casos, proveedores. Una solicitud incompleta puede demorar el ingreso o generar permisos excesivos.
Este procedimiento es genérico. Cada empresa debe definir quién autoriza, qué sistemas intervienen, qué evidencia conserva y qué plazos necesita. Las contraseñas no deben circular dentro de tickets o planillas sin protección.
Puntos clave
- Nombre, puesto, área, responsable, fecha, sede y modalidad de trabajo.
- Perfil o empleado de referencia revisado, no copiado sin criterio.
- Licencias, grupos, aplicaciones, carpetas y permisos con aprobación.
- Equipo, accesorios, teléfono, VPN y elementos de seguridad requeridos.
- MFA, recuperación, políticas y aceptación de entrega documentadas.
Recomendaciones
- Recibir la solicitud por canal oficial con anticipación y aprobación del responsable.
- Validar identidad, puesto, fecha y matriz de accesos aplicable.
- Crear cuenta individual, asignar licencias mínimas y registrar cambios.
- Preparar equipo administrado, actualizado, cifrado y asociado al inventario.
- Entregar acceso inicial mediante un mecanismo seguro y registrar MFA.
- Probar inicio de sesión, aplicaciones, impresión, comunicación y acceso remoto necesarios.
- Confirmar con el responsable y cerrar la solicitud con activos y permisos otorgados.
Riesgos y advertencias
- Copiar todos los permisos de otra persona perpetúa accesos innecesarios.
- Crear cuentas compartidas reduce trazabilidad y complica la baja.
- Entregar credenciales por canales inseguros expone la cuenta antes de su uso.
Cómo validar el resultado
- El usuario accede solo a sistemas aprobados y completa MFA.
- El inventario relaciona equipo, accesorios y responsable.
- El responsable del área confirma que el perfil permite trabajar sin privilegios adicionales.
Buenas prácticas
Utilizar perfiles por función como punto de partida, mantener separación de funciones y revisar accesos después del período inicial. Toda excepción debe tener motivo y aprobación.
Próximos pasos
Transformar esta guía en un checklist propio con plazos, aprobadores, sistemas y evidencia. La automatización debe implementarse solo después de estabilizar el proceso.
Autoevaluación inicial de madurez tecnológica
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Ofrecer una línea de base conversacional que ayude a priorizar preguntas y acciones; no reemplaza una auditoría ni certifica seguridad.
Contexto
La madurez tecnológica describe qué tan repetibles, visibles y controlados son los procesos IT. Una organización puede tener herramientas modernas y baja madurez si depende de personas aisladas, carece de documentación o no prueba sus controles.
Califique cada afirmación de cero a tres: cero si no existe, uno si se realiza de forma informal, dos si está definido pero presenta brechas, y tres si se aplica, mide y revisa. Registre evidencia y dudas; evitar respuestas optimistas mejora el valor del ejercicio.
Puntos clave
- Gestión: responsables, inventario, proveedores, presupuesto y plan de renovación.
- Soporte: canal de tickets, prioridades, escalamiento, resoluciones y métricas.
- Identidad: cuentas individuales, altas, bajas, MFA, privilegios y revisiones.
- Infraestructura: diagramas, versiones soportadas, capacidad, mantenimiento y monitoreo.
- Continuidad: alcance de backup, separación, retención, pruebas, RPO y RTO.
- Gobierno: políticas, cambios, incidentes, capacitación y seguimiento de mejoras.
Recomendaciones
- Reunir a responsables de negocio y tecnología y acordar el alcance.
- Puntuar cada dominio con una breve evidencia o ejemplo.
- Identificar controles inexistentes que expongan procesos críticos.
- Elegir hasta cinco mejoras para los próximos noventa días.
- Asignar responsable, fecha y criterio de validación a cada mejora.
- Repetir la evaluación en seis meses y comparar evidencia, no solo puntaje.
Riesgos y advertencias
- Sumar puntos sin considerar criticidad puede ocultar una brecha grave detrás de varios controles menores.
- Responder sin evidencia produce una percepción de madurez difícil de sostener.
- Utilizar el resultado para buscar culpables reduce la sinceridad y la mejora.
Cómo validar el resultado
- Cada calificación relevante tiene evidencia, responsable o una tarea de verificación.
- Las prioridades se relacionan con procesos e impactos concretos.
- El plan resultante tiene pocas acciones alcanzables y criterios de cierre.
Buenas prácticas
Interpretar por dominio y riesgo, no como nota global. La evolución se demuestra con procesos repetibles, documentación vigente, pruebas y decisiones basadas en información.
Próximos pasos
Si existen respuestas desconocidas o contradictorias, un relevamiento inicial puede validar inventario, accesos, infraestructura, backups y dependencias antes de definir un plan de mejora.
Qué es MFA y por qué debe activarse
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Explicar el valor y las limitaciones de MFA, y orientar una implementación gradual que contemple usuarios, administradores y recuperación.
Contexto
La autenticación multifactor solicita al menos dos pruebas de identidad de categorías diferentes, por ejemplo una contraseña y una aprobación desde un dispositivo registrado. Si una contraseña se filtra mediante phishing o reutilización, el segundo factor agrega una barrera importante.
MFA no vuelve invulnerable una cuenta. Un atacante puede intentar engañar al usuario para que apruebe una solicitud, robar una sesión o explotar métodos de recuperación débiles. Por eso debe combinarse con capacitación, registros, políticas de acceso y procedimientos de soporte.
Puntos clave
- Las aplicaciones autenticadoras y llaves de seguridad ofrecen mejores controles que mensajes SMS en escenarios sensibles.
- Las cuentas administrativas requieren protección prioritaria y no deberían utilizarse para tareas diarias.
- Los métodos de recuperación deben registrarse y revisarse de forma controlada.
- Las cuentas de emergencia necesitan controles compensatorios, monitoreo y uso excepcional.
- Las solicitudes inesperadas de aprobación deben rechazarse y reportarse.
Recomendaciones
- Inventariar usuarios, cuentas compartidas, administradores y aplicaciones antiguas.
- Definir métodos admitidos y un proceso de registro y recuperación.
- Realizar un piloto representativo y preparar comunicación y soporte.
- Aplicar políticas por grupos, verificando protocolos y aplicaciones incompatibles.
- Monitorear rechazos, ubicaciones inusuales y cambios de método de autenticación.
Riesgos y advertencias
- Activar MFA sin recuperación puede dejar usuarios legítimos sin acceso.
- Aceptar repetidamente solicitudes no iniciadas puede permitir un ataque de fatiga de MFA.
- Mantener autenticación heredada puede evitar los controles modernos.
Cómo validar el resultado
- Las cuentas alcanzadas solicitan el segundo factor según la política definida.
- Soporte puede recuperar acceso verificando identidad sin pedir contraseñas.
- Las cuentas administrativas y excepciones aparecen en un reporte revisable.
Buenas prácticas
Priorizar administradores y accesos remotos, utilizar métodos resistentes al phishing cuando sea posible y revisar excepciones. La capacitación debe enseñar a reconocer y reportar solicitudes inesperadas.
Próximos pasos
Una revisión de identidad permite identificar cuentas sin MFA, métodos débiles, privilegios excesivos y aplicaciones que todavía dependen de autenticación heredada.
Qué es el phishing y cómo reconocerlo
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Ayudar a usuarios a reconocer intentos de engaño y actuar rápido sin investigar por cuenta propia ni destruir evidencia útil.
Contexto
El phishing utiliza mensajes que aparentan provenir de una persona o servicio confiable para obtener credenciales, dinero, datos o ejecución de archivos. Puede llegar por correo, mensajería, redes sociales, llamadas o códigos QR.
Los ataques actuales pueden estar bien escritos y utilizar información pública. Ninguna señal aislada confirma el fraude; importa comparar contexto, remitente, destino del enlace, urgencia, solicitud y canal habitual.
Puntos clave
- Urgencia inesperada, amenaza o pedido de confidencialidad.
- Cambio repentino de cuenta bancaria o forma de pago.
- Enlace cuyo dominio no coincide con el servicio esperado.
- Archivo no solicitado o que pide habilitar contenido.
- Solicitud de contraseña, código MFA o aprobación que el usuario no inició.
- Mensaje de una autoridad que evita los procesos normales de autorización.
Recomendaciones
- No responder, no abrir adjuntos y no iniciar sesión desde el enlace.
- Verificar el pedido mediante un canal conocido e independiente.
- Utilizar la función de reporte o enviar el mensaje al canal oficial de soporte.
- Informar si se hizo clic, se ingresaron datos o se aprobó una solicitud.
- Conservar el mensaje hasta recibir indicaciones; no reenviarlo a grupos amplios.
Riesgos y advertencias
- Responder al mismo remitente no verifica identidad si su cuenta está comprometida.
- Abrir el enlace para comprobarlo expone al usuario y puede registrar actividad.
- Ocultar un clic por temor retrasa las acciones de contención.
Cómo validar el resultado
- El usuario conoce el canal oficial de reporte.
- Soporte recibe el mensaje original o la evidencia necesaria para analizarlo.
- Si hubo interacción, se revisan sesión, credenciales, MFA y actividad posterior.
Buenas prácticas
Promover el reporte temprano y sin sanciones, realizar ejercicios breves y utilizar controles técnicos de correo. La capacitación debe reforzarse con procesos de pago y cambios sensibles que requieran verificación independiente.
Próximos pasos
Definir un procedimiento visible para reportar mensajes y realizar una campaña que mida reporte, no solo clics. Ante una interacción real, debe intervenir personal autorizado.
Diferencias entre soporte reactivo y gestión IT proactiva
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Distinguir dos modelos de atención y mostrar qué capacidades necesita una empresa para pasar de la urgencia permanente a una gestión previsible.
Contexto
El soporte reactivo comienza cuando un usuario informa una falla. Es necesario y nunca desaparece, pero si representa casi toda la actividad de IT, la empresa trabaja sobre síntomas y acumula causas sin resolver.
La gestión proactiva agrega inventario, mantenimiento, monitoreo, análisis de tendencias, revisión de seguridad y planificación. Su objetivo no es prometer que nunca habrá incidentes, sino reducir su frecuencia, anticipar capacidad y recuperar la operación con mayor control.
Puntos clave
- Reactivo mide principalmente tickets resueltos; proactivo también observa recurrencia, capacidad y riesgo.
- Reactivo depende del aviso del usuario; proactivo utiliza alertas, revisiones y calendarios.
- Reactivo suele documentar la solución puntual; proactivo registra causas, cambios y prevención.
- Proactividad no significa realizar cambios sin autorización ni mantener herramientas innecesarias.
- El equilibrio depende de criticidad, tamaño, presupuesto y tolerancia a interrupciones.
Recomendaciones
- Clasificar los últimos incidentes e identificar cuáles fueron repetitivos o previsibles.
- Definir activos y servicios que requieren revisiones o monitoreo.
- Crear un calendario mínimo de mantenimiento, actualizaciones y pruebas de recuperación.
- Establecer indicadores de recurrencia, disponibilidad y capacidad, además de tiempos de respuesta.
- Priorizar mejoras según riesgo e impacto, no según la herramienta más novedosa.
Riesgos y advertencias
- Llamar proactivo a un servicio sin inventario, documentación ni revisiones produce una falsa sensación de control.
- Demasiadas alertas sin responsables generan fatiga y terminan ignorándose.
- Cambios preventivos sin prueba o reversión también pueden causar interrupciones.
Cómo validar el resultado
- Disminuyen los incidentes repetitivos o se documenta por qué continúan.
- Los recursos críticos tienen umbrales y responsables definidos.
- Existe un plan visible de mejoras y mantenimiento con prioridades acordadas.
Buenas prácticas
Comenzar con pocos controles sostenibles: inventario, backups verificados, capacidad de disco, vencimientos y revisión de accesos. La madurez surge de la constancia, no de acumular paneles.
Próximos pasos
Una línea de base de incidentes, activos y riesgos permite decidir qué controles preventivos aportan más valor durante los próximos noventa días.
Qué información debe contener un inventario tecnológico
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Definir una estructura mínima de inventario que permita saber qué activos existen, quién los utiliza, qué función cumplen y qué riesgos requieren atención.
Contexto
Un inventario tecnológico no es solo una lista de computadoras. Debe relacionar activos físicos, máquinas virtuales, licencias, servicios cloud, redes, responsables, ubicaciones, garantías y dependencias operativas.
El nivel de detalle debe responder preguntas reales: quién tiene el equipo, qué sistema soporta, cuándo vence la garantía, qué proveedor interviene y qué ocurriría si dejara de funcionar. Registrar datos sin un proceso de actualización produce una fotografía rápidamente obsoleta.
Puntos clave
- Identificador único, tipo, marca, modelo, número de serie y estado.
- Usuario responsable, ubicación, área, fecha de asignación y devolución.
- Sistema operativo, versión, cifrado, protección y última revisión.
- Compra, garantía, proveedor, costo, vencimientos y ciclo de renovación.
- Servicios o procesos que dependen del activo y criticidad asociada.
- Para activos lógicos: propietario, suscripción, roles administrativos y método de recuperación.
Recomendaciones
- Definir un alcance inicial y una convención de identificadores.
- Importar fuentes disponibles y verificar físicamente una muestra.
- Asignar un propietario del dato y responsables por altas, movimientos y bajas.
- Relacionar el inventario con tickets, usuarios, contratos y renovaciones cuando la herramienta lo permita.
- Realizar conciliaciones periódicas y registrar excepciones.
Riesgos y advertencias
- Guardar contraseñas o secretos dentro del inventario mezcla activos con credenciales y aumenta la exposición.
- Depender solo de descubrimiento automático omite contexto de negocio y responsables.
- Eliminar registros de equipos dados de baja impide conservar trazabilidad; conviene archivarlos.
Cómo validar el resultado
- Es posible ubicar al responsable de cada activo crítico.
- Las cantidades registradas coinciden con una muestra física y con compras recientes.
- Los vencimientos y equipos fuera de soporte pueden filtrarse y priorizarse.
Buenas prácticas
Mantener campos obligatorios mínimos, catálogos controlados y evidencia de la última verificación. El inventario debe integrarse al alta, entrega, traslado, mantenimiento y baja del activo.
Próximos pasos
Comenzar por usuarios, equipos, servidores, red, servicios cloud y licencias críticas. Luego incorporar dependencias, contratos y costos sin intentar modelar todo desde el primer día.
Por qué todas las solicitudes de soporte deberían registrarse como tickets
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Explicar por qué mensajes, llamadas y conversaciones informales deben convertirse en registros gestionables sin volver burocrática la atención.
Contexto
Un ticket es el registro operativo de una necesidad: conserva quién la informó, cuándo ocurrió, qué impacto tiene, quién la atiende, qué acciones se realizaron y cómo terminó. El canal puede ser correo, portal o teléfono, pero el resultado debe quedar registrado.
Cuando las solicitudes quedan en chats personales, cada técnico construye su propia cola y la empresa pierde visibilidad. Los temas urgentes compiten con pedidos menores, las ausencias interrumpen el seguimiento y las soluciones no se reutilizan.
Puntos clave
- Permite ordenar por impacto y urgencia en lugar de por insistencia.
- Mantiene continuidad cuando cambia la persona que atiende.
- Registra comunicaciones, autorizaciones, tiempos y resolución.
- Hace visibles problemas repetitivos y necesidades de capacitación.
- Aporta evidencia para revisar capacidad y nivel de servicio.
Recomendaciones
- Definir uno o pocos canales oficiales y comunicar cuándo utilizarlos.
- Solicitar datos mínimos: usuario, equipo o servicio, momento, síntomas e impacto.
- Establecer categorías y prioridades simples, evitando listas difíciles de mantener.
- Convertir pedidos recibidos por excepción en tickets sin obligar al usuario a repetir todo.
- Cerrar con una resolución comprensible y confirmar el resultado cuando corresponda.
Riesgos y advertencias
- Usar el ticket como barrera para negar atención deteriora la adopción.
- Medir solo cantidad o velocidad puede incentivar cierres prematuros.
- Registrar datos sensibles innecesarios dentro del ticket aumenta la exposición.
Cómo validar el resultado
- Las solicitudes activas tienen responsable, prioridad y próxima acción.
- Los usuarios pueden consultar el estado sin depender de una persona específica.
- Las resoluciones frecuentes son identificables y reutilizables.
Buenas prácticas
El proceso debe ser fácil para el usuario y riguroso para el equipo. Automatizar confirmaciones y plantillas ayuda, pero no reemplaza una comunicación clara ni la clasificación humana.
Próximos pasos
Revisar durante un mes cuántos pedidos llegan por canales informales y diseñar un flujo que los capture sin perder urgencia ni contexto.
Qué es un SLA y cómo interpretarlo
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Dar criterios para evaluar un SLA sin confundir tiempo de respuesta con resolución garantizada ni cobertura con disponibilidad absoluta.
Contexto
Un acuerdo de nivel de servicio, o SLA, define compromisos medibles entre quien presta y quien recibe un servicio. Puede incluir horario de cobertura, tiempo de primera respuesta, objetivos de restauración, disponibilidad y frecuencia de reportes.
Para interpretarlo hay que leer también cómo se mide: desde qué evento comienza el reloj, qué horarios cuentan, cuándo se pausa, qué prioridad aplica y qué información debe aportar el solicitante. Un número aislado no describe la experiencia completa.
Puntos clave
- Tiempo de respuesta indica cuándo comienza la atención, no necesariamente cuándo termina.
- Tiempo de restauración puede priorizar recuperar la operación antes de resolver la causa definitiva.
- La prioridad combina impacto, urgencia, cantidad de usuarios y alternativas disponibles.
- La cobertura define días, horarios, canales y guardias; no debe suponerse.
- Exclusiones, dependencias de terceros y obligaciones del cliente deben ser explícitas.
Recomendaciones
- Identificar servicios críticos y el impacto real de su indisponibilidad.
- Definir una matriz de prioridades con ejemplos comprensibles.
- Acordar punto de inicio, pausas, escalamiento y forma de medición.
- Separar objetivos internos, compromisos contractuales y expectativas de negocio.
- Revisar resultados y excepciones con una periodicidad acordada.
Riesgos y advertencias
- Prometer resolución en plazos fijos para cualquier causa puede ser técnicamente inviable.
- Prioridades declaradas como urgentes por defecto vuelven inútil el modelo.
- Un SLA sin capacidad, monitoreo ni escalamiento es solo una declaración.
Cómo validar el resultado
- Usuarios y equipo de soporte clasifican ejemplos de forma consistente.
- Los reportes distinguen respuesta, restauración, resolución y pausas.
- Las excepciones se analizan y generan acciones, no se ocultan en promedios.
Buenas prácticas
Usar pocos niveles, ejemplos reales y lenguaje operativo. Complementar promedios con percentiles, recurrencia y satisfacción evita que una métrica favorable oculte incidentes graves.
Próximos pasos
Seleccionar tres servicios críticos y definir para cada uno cobertura, prioridad, responsables, dependencia de proveedores y objetivo de comunicación.
Diferencias entre OneDrive, SharePoint y Teams
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Evitar duplicaciones y permisos desordenados mediante una regla clara de uso para archivos personales, contenido de equipos y colaboración cotidiana.
Contexto
OneDrive, SharePoint y Teams trabajan sobre la misma plataforma de archivos, pero representan contextos distintos. OneDrive está orientado al trabajo individual; SharePoint organiza información perteneciente a la empresa o a un área; Teams agrega conversaciones, reuniones y colaboración sobre sitios de SharePoint.
La pregunta principal no es qué aplicación resulta más cómoda, sino quién debe conservar la información si una persona cambia de puesto o deja la empresa. Los documentos operativos deberían pertenecer al equipo o proceso, no depender de la cuenta personal de quien los creó.
Puntos clave
- OneDrive es apropiado para borradores y archivos de trabajo personal aún no incorporados a un proceso compartido.
- SharePoint aloja bibliotecas, políticas, procedimientos y documentación con propiedad organizacional.
- Cada equipo de Teams utiliza un sitio de SharePoint para sus archivos de canal.
- Compartir un enlace no cambia automáticamente la propiedad ni la clasificación del documento.
- La estructura debe seguir procesos y responsabilidades, no reproducir sin criterio carpetas históricas.
Recomendaciones
- Clasificar ejemplos reales como personales, de equipo, departamentales o corporativos.
- Definir propietarios para equipos, sitios y bibliotecas.
- Crear pocas ubicaciones con nombres y propósito comprensibles.
- Preferir grupos y equipos para permisos recurrentes en lugar de compartir persona por persona.
- Revisar enlaces externos, miembros inactivos y sitios sin propietario.
Riesgos y advertencias
- Guardar documentación empresarial solo en OneDrive dificulta continuidad y baja de usuarios.
- Crear un Team para cada conversación produce sitios y permisos difíciles de gobernar.
- Sin capacitación, la sincronización local puede generar copias, conflictos o consumo excesivo de disco.
Cómo validar el resultado
- Los usuarios pueden explicar dónde guardar tres tipos frecuentes de documentos.
- Cada sitio y equipo relevante tiene al menos un propietario responsable.
- La información crítica permanece accesible ante la ausencia de su autor.
Buenas prácticas
Definir reglas simples, acompañarlas con ejemplos y revisar la arquitectura cada seis meses. La gobernanza debe incluir creación, nombres, propietarios, acceso externo, retención y archivo.
Próximos pasos
Elegir un proceso concreto, revisar dónde viven hoy sus archivos y migrar solo después de acordar propiedad, permisos y estructura futura.
Cómo preparar una migración a Microsoft 365
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Preparar una migración controlada que reduzca interrupciones, pérdida de información, permisos incorrectos y sorpresas de licenciamiento.
Contexto
Una migración no consiste solo en copiar buzones. Cambia identidades, métodos de acceso, DNS, dispositivos, aplicaciones, permisos y formas de colaboración. La calidad del relevamiento determina gran parte del riesgo del proyecto.
Antes de elegir una herramienta deben conocerse usuarios activos, alias, listas, buzones compartidos, volúmenes, archivos, calendarios, dispositivos, integraciones y requisitos legales. También hay que decidir qué información se migra, qué se archiva y qué puede depurarse con aprobación.
Puntos clave
- Definir alcance, responsables, criterios de éxito y ventana de cambio.
- Verificar propiedad del dominio y capacidad para modificar DNS.
- Mapear identidades, licencias, grupos, delegaciones y aplicaciones que envían correo.
- Medir volumen, velocidad disponible y límites de origen y destino.
- Preparar coexistencia, comunicación, soporte y reversión para los eventos críticos.
Recomendaciones
- Crear un inventario de usuarios, objetos, datos, permisos e integraciones.
- Diseñar la identidad y el licenciamiento objetivo antes de crear cuentas masivamente.
- Ejecutar un piloto con usuarios y escenarios representativos.
- Validar correo, calendarios, permisos, dispositivos móviles y aplicaciones.
- Planificar corte, comunicación, soporte intensivo y tareas posteriores.
Riesgos y advertencias
- Modificar DNS sin registrar valores anteriores dificulta la reversión.
- Migrar cuentas obsoletas y permisos históricos reproduce problemas del entorno anterior.
- Subestimar aplicaciones, multifunción y sistemas que envían correo provoca fallas posteriores.
Cómo validar el resultado
- El piloto demuestra envío, recepción, acceso, permisos y uso desde dispositivos previstos.
- Cada objeto del origen tiene destino, exclusión aprobada o tratamiento documentado.
- Existe una lista de verificación de corte con responsables y criterios para continuar o revertir.
Buenas prácticas
Separar decisiones de negocio, preparación técnica, transferencia y adopción. Conservar evidencia de conteos y pruebas antes y después permite detectar diferencias de forma temprana.
Próximos pasos
Realizar un relevamiento de identidades, buzones, permisos, dominios, integraciones y volumen para construir un plan, una estimación y un piloto realistas.
Qué controles mínimos de seguridad debería tener una pyme
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Priorizar controles sostenibles que reduzcan riesgos frecuentes sin suponer presupuesto, personal o herramientas ilimitadas.
Contexto
La seguridad de una pyme no depende de una herramienta única. Requiere capas sobre identidad, dispositivos, información, red, copias de seguridad, proveedores y personas. La prioridad debe basarse en activos críticos y escenarios de pérdida concretos.
Una línea de base permite saber qué existe, qué falta y quién responde. Los controles deben adaptarse al negocio y revisarse; aplicar una lista sin contexto puede dejar fuera el sistema más importante o crear bloqueos innecesarios.
Puntos clave
- MFA, cuentas individuales y privilegios administrativos separados.
- Actualizaciones, cifrado, protección de endpoints e inventario de equipos.
- Filtrado de correo, capacitación y proceso para reportar incidentes.
- Backups separados, protegidos y probados con objetivos de recuperación.
- Firewall administrado, acceso remoto controlado y redes segmentadas cuando corresponda.
- Altas, bajas, revisiones de acceso, registros y responsables documentados.
Recomendaciones
- Identificar información, servicios y procesos cuya pérdida detendría la operación.
- Relevar identidades, equipos, accesos externos, backups y proveedores.
- Cerrar exposiciones críticas y cuentas obsoletas antes de proyectos complejos.
- Asignar responsables y fechas a un plan de mejoras priorizado.
- Probar recuperación y respuesta mediante ejercicios acotados.
Riesgos y advertencias
- Comprar herramientas sin operación, alertas ni responsables genera controles nominales.
- Concentrar privilegios y conocimiento en una sola persona aumenta riesgo operativo.
- Confundir sincronización con backup deja datos expuestos a borrado o ransomware.
Cómo validar el resultado
- No existen cuentas activas sin propietario conocido en sistemas críticos.
- Los equipos administrados reportan estado de actualización, cifrado y protección.
- Se puede restaurar una muestra de información dentro de un plazo aceptable.
- Usuarios y responsables conocen el canal de incidentes y las primeras acciones.
Buenas prácticas
Trabajar por ciclos: relevar, priorizar, implementar, medir y revisar. Documentar excepciones y aceptar riesgos de forma explícita es mejor que asumir que todo está cubierto.
Próximos pasos
Una revisión de seguridad básica puede convertir esta línea de base en un plan de noventa días con responsables, dependencias y criterios de validación.
Diferencia entre router, switch y firewall
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Dar un modelo simple para comprender cómo se conectan dispositivos, redes e Internet y dónde se aplican controles de seguridad.
Contexto
Un switch conecta dispositivos dentro de una red local y reenvía tráfico según direcciones de enlace. Un router comunica redes diferentes y decide por dónde enviar paquetes. Un firewall permite, bloquea o inspecciona comunicaciones según una política.
Un mismo dispositivo puede ofrecer las tres funciones, especialmente en oficinas pequeñas, pero siguen siendo responsabilidades distintas. Entenderlas ayuda a diagnosticar fallas, diseñar segmentación y evaluar capacidad sin depender del nombre comercial del equipo.
Puntos clave
- El switch aporta puertos, velocidad local, VLAN y, según el modelo, alimentación PoE.
- El router conecta subredes y suele manejar rutas hacia Internet o entre sedes.
- El firewall aplica políticas, registra eventos y puede inspeccionar aplicaciones o amenazas.
- NAT traduce direcciones, pero no reemplaza una política de seguridad bien definida.
- Rendimiento, redundancia, soporte y capacidad de administración importan tanto como las funciones declaradas.
Recomendaciones
- Dibujar proveedores, enlaces, firewall o router, switches, puntos de acceso y redes lógicas.
- Identificar qué equipo entrega DHCP, DNS, VPN, rutas y reglas de seguridad.
- Registrar modelos, versiones, respaldo de configuración y responsables.
- Comparar capacidad real con tráfico, cantidad de usuarios, VPN y servicios inspeccionados.
- Separar cambios de conectividad de cambios de seguridad y documentar ambos.
Riesgos y advertencias
- Reemplazar un equipo sin conocer todas sus funciones puede interrumpir servicios aparentemente no relacionados.
- Administrar todos los componentes con cuentas compartidas reduce trazabilidad.
- Equipos domésticos suelen carecer de soporte, registros, segmentación y respaldo adecuado para una operación empresarial.
Cómo validar el resultado
- El diagrama identifica quién enruta, conmuta, filtra y entrega servicios auxiliares.
- Las configuraciones críticas tienen respaldo y fecha de última verificación.
- Las reglas permiten solo los flujos necesarios entre redes y hacia Internet.
Buenas prácticas
Mantener diagramas lógico y físico, nombres consistentes y control de cambios. Las funciones integradas pueden ser válidas si la capacidad, disponibilidad y administración responden al riesgo del negocio.
Próximos pasos
Relevar los equipos actuales y documentar responsabilidades permite detectar puntos únicos de falla, configuraciones desconocidas y necesidades reales de renovación.
Qué es una VLAN y por qué utilizarla
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Explicar la segmentación lógica y los pasos de diseño necesarios para separar usuarios, invitados, servidores, telefonía y dispositivos sin improvisar reglas.
Contexto
Una VLAN crea un dominio de red lógico independiente sobre switches y enlaces compartidos. Los dispositivos de VLAN distintas necesitan un router o firewall para comunicarse, lo que permite aplicar reglas y observar flujos entre segmentos.
La segmentación reduce alcance de difusión, organiza direccionamiento y limita movimientos no necesarios. No es seguridad automática: si el enrutamiento permite cualquier tráfico entre VLAN, la separación aporta poco frente a una intrusión.
Puntos clave
- Cada VLAN necesita propósito, identificador, subred, gateway, DHCP y responsable.
- Los puertos de acceso pertenecen normalmente a una VLAN; los enlaces troncales transportan varias etiquetas.
- El firewall debe permitir solo comunicaciones justificadas entre segmentos.
- WiFi corporativo, invitados e IoT suelen requerir políticas distintas.
- La administración de equipos de red debería estar separada y restringida.
Recomendaciones
- Relevar flujos actuales y agrupar dispositivos por función, confianza y criticidad.
- Diseñar nombres, identificadores y subredes evitando superposición.
- Definir matriz de comunicaciones necesarias antes de crear reglas.
- Probar con un segmento piloto y validar DHCP, DNS, impresión, aplicaciones y monitoreo.
- Migrar por etapas con respaldo de configuración y reversión documentada.
Riesgos y advertencias
- Cambiar una VLAN de forma remota puede cortar el acceso de administración.
- Troncales o VLAN nativas inconsistentes producen fallas difíciles de diagnosticar.
- Reglas amplias entre segmentos conservan una red plana bajo nombres diferentes.
Cómo validar el resultado
- Cada dispositivo recibe dirección y servicios correctos para su segmento.
- Las comunicaciones no autorizadas se bloquean y quedan registradas cuando corresponde.
- El diagrama y la matriz coinciden con la configuración efectiva.
Buenas prácticas
Aplicar cambios en ventana controlada, conservar acceso alternativo y documentar puertos, troncales, subredes y reglas. Revisar periódicamente excepciones temporales.
Próximos pasos
Una evaluación de red puede identificar grupos de confianza, dependencias y una secuencia de segmentación que minimice interrupciones.
Cuándo una empresa necesita un servidor local
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Evitar decisiones basadas en modas y evaluar si una carga necesita ejecutarse en la oficina, en un centro de datos o como servicio en la nube.
Contexto
Un servidor local sigue siendo válido cuando existen aplicaciones que lo requieren, grandes volúmenes de datos internos, equipos industriales, baja latencia, restricciones de conectividad o necesidades específicas de control. También puede formar parte de una arquitectura híbrida.
La comparación debe incluir ciclo completo: hardware, energía, refrigeración, licencias, backups, administración, renovaciones y recuperación. La nube traslada responsabilidades, pero no elimina gestión de identidades, datos, costos ni continuidad.
Puntos clave
- Dependencias técnicas y soporte del proveedor de la aplicación.
- Calidad y redundancia de Internet en cada sede.
- Volumen de datos, latencia, crecimiento y ventanas de respaldo.
- Requisitos regulatorios, contractuales y de ubicación de información.
- Capacidad interna para operar, actualizar, monitorear y recuperar la plataforma.
Recomendaciones
- Inventariar aplicaciones, usuarios, integraciones, datos y criticidad.
- Medir consumo actual y proyectar capacidad y crecimiento.
- Comparar escenarios local, cloud e híbrido con costos de tres a cinco años.
- Diseñar backup, continuidad, soporte y renovación para cada alternativa.
- Realizar una prueba cuando existan dudas de rendimiento o compatibilidad.
Riesgos y advertencias
- Mantener un servidor sin soporte por evitar una migración acumula riesgo y deuda técnica.
- Mover una aplicación sensible a Internet sin probar conectividad puede degradar la operación.
- Confundir alta disponibilidad con backup deja escenarios de borrado o corrupción sin respuesta.
Cómo validar el resultado
- La alternativa elegida satisface rendimiento, recuperación y soporte requeridos.
- Los costos incluyen operación, licencias, conectividad, respaldo y renovación.
- Existe un responsable y un plan ante indisponibilidad de cada dependencia crítica.
Buenas prácticas
Documentar supuestos y revisar la decisión cuando cambien aplicaciones, sedes, conectividad o volumen. Diseñar salida y portabilidad evita quedar atrapado en una plataforma.
Próximos pasos
Un relevamiento de infraestructura y aplicaciones permite dimensionar alternativas y detectar si el problema real es capacidad, soporte, conectividad o diseño.
Qué es la virtualización
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Explicar el modelo de virtualización y los criterios de capacidad, respaldo y disponibilidad que deben acompañar una implementación empresarial.
Contexto
La virtualización permite que un servidor físico ejecute varias máquinas virtuales, cada una con sistema operativo, recursos y función propios. El hipervisor asigna procesador, memoria, almacenamiento y red, y ofrece herramientas de administración.
Consolidar facilita aprovisionamiento, aislamiento, mantenimiento y recuperación, pero también concentra cargas. Una falla del host, almacenamiento o administración puede afectar simultáneamente varios servicios si no existe redundancia o un plan de recuperación.
Puntos clave
- Host físico, hipervisor, almacenamiento, redes virtuales y máquinas forman una plataforma única.
- Asignar recursos no garantiza que existan físicamente durante picos de demanda.
- Una instantánea es útil para cambios acotados, pero no sustituye un backup independiente.
- Migración en vivo y alta disponibilidad requieren diseño, licencias y pruebas.
- Cada máquina debe documentar función, propietario, recursos, red, backup y dependencias.
Recomendaciones
- Medir cargas actuales y definir crecimiento y margen de operación.
- Diseñar almacenamiento, red, administración y protección del hipervisor.
- Separar accesos administrativos y mantener versiones soportadas.
- Configurar monitoreo de host y de cada máquina virtual.
- Probar respaldo, restauración y procedimientos de mantenimiento.
Riesgos y advertencias
- Sobredimensionar virtualmente memoria o almacenamiento sin monitoreo puede afectar todas las cargas.
- Guardar backups en el mismo sistema que protege mantiene un punto único de falla.
- Crear máquinas sin ciclo de vida produce consumo y sistemas olvidados.
Cómo validar el resultado
- La capacidad soporta picos y pérdida prevista de componentes según el diseño.
- Las máquinas críticas tienen respaldo probado y dependencias conocidas.
- El mantenimiento del host cuenta con ventana, comunicación y reversión.
Buenas prácticas
Mantener inventario de máquinas, plantillas seguras, control de cambios y revisión de capacidad. Eliminar o archivar recursos solo después de confirmar propietarios, datos y retención.
Próximos pasos
Antes de virtualizar o renovar, medir consumo real y definir objetivos de recuperación permite dimensionar correctamente hosts, almacenamiento y backup.
Qué es un backup y qué no es un backup
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Ayudar a responsables de empresas a reconocer si realmente cuentan con copias recuperables para errores, fallas, ataques y desastres.
Contexto
Un backup es una copia separada y administrada que permite recuperar datos o sistemas de un momento determinado. Debe tener alcance, frecuencia, retención, protección, responsable y procedimiento de restauración.
Sincronización replica cambios y puede propagar borrados o corrupción. RAID y alta disponibilidad reducen interrupciones por fallas específicas, pero no conservan necesariamente versiones históricas. Un archivo busca conservación; tampoco reemplaza por sí solo una estrategia de recuperación.
Puntos clave
- Definir qué se protege y qué elementos son necesarios para restaurar el servicio completo.
- Separar copias del entorno protegido mediante cuentas, almacenamiento o ubicación.
- Conservar versiones según necesidades operativas, legales y de ransomware.
- Cifrar cuando corresponda y controlar quién puede borrar o modificar copias.
- Monitorear trabajos y realizar restauraciones de prueba con evidencia.
Recomendaciones
- Inventariar datos, aplicaciones, configuraciones y dependencias críticas.
- Definir RPO, RTO y retención con responsables del negocio.
- Diseñar copias locales y externas evitando credenciales y fallas comunes.
- Configurar alertas y revisión diaria o periódica de resultados.
- Probar recuperación de archivos y sistemas completos en escenarios representativos.
Riesgos y advertencias
- Un trabajo informado como exitoso puede contener datos incompletos o inutilizables.
- Copias conectadas con los mismos privilegios pueden ser cifradas o eliminadas durante un ataque.
- No respaldar configuraciones, claves institucionales o documentación puede impedir restaurar el servicio.
Cómo validar el resultado
- Se restaura una muestra y se comprueba integridad y uso, no solo existencia del archivo.
- Los tiempos observados son compatibles con los objetivos acordados.
- Responsables reciben y atienden fallas de backup dentro de un plazo definido.
Buenas prácticas
Aplicar separación, múltiples versiones y pruebas. Registrar resultados, duración y hallazgos de cada restauración, y revisar la estrategia cuando cambian aplicaciones o volúmenes.
Próximos pasos
Una revisión de backups debe comparar alcance real, retención, separación y pruebas con el impacto que la empresa está dispuesta a aceptar.
Qué significan RPO y RTO
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Traducir necesidades del negocio en objetivos de recuperación medibles y distinguirlos de garantías o resultados automáticos.
Contexto
RPO es el punto objetivo de recuperación: expresa cuánta información reciente podría perderse, medido como tiempo. Un RPO de cuatro horas implica diseñar copias o replicación para no retroceder más que ese intervalo en condiciones previstas.
RTO es el tiempo objetivo de recuperación: cuánto debería tardar el servicio en volver a un nivel acordado después de una interrupción. Ambos son objetivos de diseño y deben validarse; no son garantías por escribirlos en un documento.
Puntos clave
- Cada proceso puede necesitar objetivos diferentes según impacto y horario.
- Menores RPO y RTO suelen requerir más automatización, redundancia, capacidad y costo.
- Recuperar infraestructura no garantiza que aplicaciones y datos funcionen correctamente.
- Dependencias de identidad, red, proveedores y personas deben incluirse.
- El tiempo se mide desde un evento definido hasta un estado de servicio acordado.
Recomendaciones
- Identificar procesos y responsables, no empezar por servidores aislados.
- Estimar impacto por hora o etapa y alternativas manuales disponibles.
- Acordar RPO, RTO, prioridad y nivel mínimo de operación.
- Diseñar tecnología, documentación y personal para alcanzar los objetivos.
- Probar escenarios y ajustar objetivos o inversión según resultados.
Riesgos y advertencias
- Definir cero pérdida y recuperación inmediata sin análisis produce objetivos inviables.
- Medir solo restauración técnica ignora validación funcional y comunicación.
- No actualizar objetivos después de cambios de negocio vuelve obsoleto el plan.
Cómo validar el resultado
- Una prueba registra hora de inicio, hitos, recuperación y validación del usuario responsable.
- La pérdida observada y el tiempo total se comparan con objetivos definidos.
- Los desvíos generan acciones con responsable y fecha.
Buenas prácticas
Utilizar escenarios concretos y documentar supuestos. Diferenciar recuperación parcial, servicio degradado y operación completa ayuda a fijar objetivos realistas.
Próximos pasos
Realizar un taller breve con responsables de procesos críticos para acordar impacto, prioridades y objetivos antes de revisar la arquitectura de backup y continuidad.
Procedimiento de baja de un empleado
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Objetivo
Reducir exposición y pérdida de información mediante una baja coordinada, autorizada y verificable que respete necesidades legales y operativas.
Contexto
La baja afecta identidad, sesiones, correo, archivos, aplicaciones, VPN, dispositivos, llaves físicas y conocimiento operativo. El momento de ejecución depende del tipo de desvinculación y debe ser indicado por una autoridad definida, no decidido por IT.
Bloquear una cuenta no completa el proceso. Deben conservarse datos según política, transferirse responsabilidades, eliminar accesos externos y recuperar activos. Tampoco conviene borrar inmediatamente una identidad sin evaluar dependencias y retención.
Puntos clave
- Solicitud autorizada, fecha y hora efectiva, responsable y nivel de confidencialidad.
- Bloqueo de inicio, revocación de sesiones, tokens, VPN y métodos MFA.
- Tratamiento de correo, OneDrive, archivos, buzones y propiedad de recursos.
- Retiro de grupos, aplicaciones, roles, accesos de terceros y credenciales compartidas afectadas.
- Recuperación de equipos, teléfonos, llaves y actualización del inventario.
Recomendaciones
- Validar la orden y coordinar momento exacto con las áreas autorizadas.
- Bloquear accesos y revocar sesiones activas según el procedimiento de identidad.
- Transferir propiedad y delegaciones aprobadas sin otorgar acceso indiscriminado.
- Aplicar retención y respuestas automáticas solo con autorización y plazo definido.
- Recuperar activos, revisar estado y registrar devolución o faltantes.
- Retirar licencias y accesos externos después de preservar datos necesarios.
- Verificar en sistemas críticos y cerrar con evidencia de cada responsable.
Riesgos y advertencias
- Avisar o ejecutar fuera del momento acordado puede causar impacto laboral y operativo.
- Eliminar la cuenta antes de transferir datos puede provocar pérdida o interrupciones.
- Olvidar aplicaciones no federadas, proveedores o credenciales compartidas mantiene accesos residuales.
Cómo validar el resultado
- Los intentos de acceso y sesiones anteriores quedan revocados según la plataforma.
- Activos y propiedad de información tienen nuevo responsable o tratamiento documentado.
- La lista de sistemas, licencias y excepciones está completa y aprobada.
Buenas prácticas
Mantener una matriz de sistemas y automatizar solo acciones repetibles con evidencia. Realizar revisiones periódicas de cuentas inactivas para detectar bajas incompletas.
Próximos pasos
Crear un checklist propio y compararlo con inventario, directorio, Microsoft 365, VPN, aplicaciones y proveedores. Los casos urgentes necesitan una ruta de escalamiento específica.
Cambiar IP
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
P Cambiar IP
editar la interface
sudo nano /etc/network/interfaces
editar host
sudo nano /etc/hosts
reiniciar servicio
sudo systemctl restart networking
Base de conocimiento NeWeL
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
Base de conocimiento NeWeL
Guías y procedimientos para resolver consultas frecuentes y trabajar con tecnología de forma segura.
Elegí un artículo del menú para comenzar.
prueba000333
Artículo publicado en la base de conocimiento para resolver consultas frecuentes y procedimientos operativos.
Ver guía en esta página
prueba000333
Ubuntu 20.04
sudo apt update
sudo apt upgrade
sudo apt install postgresql -y
sudo apt install wkhtmltopdf
sudo apt-get install python3-pip
wget -q -O - https://nightly.odoo.com/odoo.key | sudo gpg --dearmor -o /usr/share/keyrings/odoo-archive-keyring.gpg
echo 'deb [signed-by=/usr/share/keyrings/odoo-archive-keyring.gpg] https://nightly.odoo.com/17.0/nightly/deb/ ./' | sudo tee /etc/apt/sources.list.d/odoo.list
sudo apt-get update && sudo apt-get install odoo
sudo apt-get upgrade
sudo pip3 install xlwt
sudo pip3 install num2words
descarga el archivo de odoo Enterprise y subirlo a algún lugar para poderlo mandar al server ahi lo pudimos temporalmente en el hosting de taff
https://www.odoo.com/es/page/download
wget taff.com.ar/odoo.deb --no-check-certificate
sudo dpkg -i odoo.deb
sudo apt-get install -f
sudo dpkg -i odoo.deb
iniciar desde ip:8069
habilitar nginx para acceder desde puerto 80
sudo apt-get install nginx
para poder escribir I par modo insert
comentar las lineas de location existentes hasta las }. con # adelante
y agregar las siguientes
location / {
proxy_pass http://127.0.0.1:8069; proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
para salir escape para salir de modo insert y :x para salir
sudo service odoo restart
ahora para instalar un certificado hay que apuntar los puertos 80 y 443 y apuntar el dominio a la ip publica.
después instalar cerbot
sudo apt install certbot python3-certbot-nginx -y
y después solicitar el certificado
certbot --nginx -d sis.newel.ar
Buenas prácticas
Cómo cargar una solicitud clara.
Cuanto más contexto tenga el pedido, más rápido podemos clasificarlo, priorizarlo y avanzar con una respuesta adecuada.
Qué ocurre
Describí el síntoma, mensaje de error, servicio afectado o comportamiento inesperado.
A quién afecta
Indicá usuario, equipo, sector, sede, correo o servicio involucrado.
Impacto operativo
Contanos si impide trabajar, afecta a varios usuarios o bloquea un proceso crítico.
Clientes NeWeL
¿Necesitás asistencia técnica?
Cargá un ticket con la mayor cantidad de información posible o consultá la base de conocimientos pública.