1. INTRODUCCIÓN Y ALCANCE

El sistema operativo es la capa de software que convierte un conjunto de procesadores, memoria, dispositivos y almacenamiento en una plataforma utilizable, controlada y compartible. Su papel no se limita a mostrar una interfaz gráfica. El sistema operativo crea abstracciones estables —procesos, hilos, espacios de direcciones, ficheros, sockets, usuarios, permisos y servicios— y aplica políticas para repartir recursos, aislar cargas de trabajo, atender dispositivos, conservar información y responder ante fallos.

Desde la perspectiva de una organización sanitaria, el sistema operativo es una dependencia transversal. Está presente en servidores de aplicaciones, bases de datos, controladores de dominio, puestos clínicos y administrativos, equipos virtuales, nodos de contenedores, terminales especializados, tabletas y teléfonos. Una aplicación puede estar correctamente diseñada y, sin embargo, fallar en producción por una configuración deficiente del sistema operativo: memoria insuficiente, permisos incorrectos, reloj desincronizado, certificados caducados, controladores incompatibles, límites de procesos, colas de entrada/salida saturadas o una actualización no validada.

El estudio del tema exige distinguir tres planos. El plano funcional explica qué servicios presta el sistema operativo y cómo se relacionan procesos, memoria, dispositivos y ficheros. El plano de administración abarca identidad, configuración, actualización, supervisión, respaldo, recuperación, seguridad y automatización. El plano de ciclo de vida comprende selección, implantación, migración, explotación, evolución y retirada. Las decisiones de un plano condicionan a los demás: por ejemplo, una migración de plataforma no es viable si las aplicaciones dependen de controladores, bibliotecas, mecanismos de autenticación o formatos de fichero no disponibles en el destino.

Para una oposición técnica conviene razonar cada concepto mediante cuatro preguntas: qué recurso gestiona, qué abstracción ofrece, qué riesgo controla y qué herramienta permite observarlo. Así, la memoria virtual no debe memorizarse solo como «usar disco cuando falta RAM»; debe entenderse como un mecanismo de traducción y protección de direcciones que proporciona aislamiento, compartición controlada, carga bajo demanda y una visión lógica de la memoria distinta de la disposición física.

También es esencial evitar equivalencias imprecisas. Sistema abierto no significa necesariamente software de código abierto; apertura se refiere principalmente a interfaces y estándares que favorecen interoperabilidad y portabilidad, mientras que código abierto describe condiciones de acceso, modificación y redistribución del código. Del mismo modo, contenedor no equivale a máquina virtual, instantánea no equivale a copia de seguridad y alta disponibilidad no equivale a recuperación ante desastres.

2. CONCEPTO, OBJETIVOS Y ARQUITECTURA DEL SISTEMA OPERATIVO

2.1. Definición funcional

Un sistema operativo es un conjunto coordinado de programas que controla la ejecución de aplicaciones, administra los recursos del computador y proporciona servicios comunes. Actúa simultáneamente como gestor de recursos, máquina extendida y mecanismo de protección. Como gestor decide quién usa CPU, memoria, dispositivos y almacenamiento. Como máquina extendida oculta detalles físicos mediante interfaces uniformes. Como mecanismo de protección separa usuarios y procesos, valida operaciones y limita el alcance de los fallos.

Las aplicaciones no deberían manipular directamente cada controlador o dispositivo. Solicitan servicios mediante bibliotecas y llamadas al sistema. Una llamada al sistema provoca una transición controlada desde modo usuario a modo privilegiado para que el núcleo realice una operación: crear un proceso, abrir un fichero, reservar memoria, enviar datos por red o modificar una configuración protegida. Esta frontera permite centralizar validaciones y evita que cualquier programa ejecute instrucciones críticas.

2.2. Objetivos clásicos

• Comodidad: proporcionar abstracciones y herramientas que simplifiquen el uso del hardware.
• Eficiencia: utilizar los recursos con buen rendimiento y evitar ociosidad innecesaria.
• Equidad y prioridad: repartir recursos conforme a políticas, clases de servicio y criticidad.
• Protección: impedir accesos no autorizados y contener errores de aplicaciones.
• Fiabilidad: detectar fallos, conservar consistencia y facilitar recuperación.
• Evolución: admitir nuevos dispositivos, arquitecturas y servicios sin romper innecesariamente las aplicaciones.
• Observabilidad: exponer métricas, estados y registros que permitan comprender el comportamiento del sistema.

2.3. Componentes

El núcleo o kernel ejecuta en modo privilegiado y contiene los mecanismos esenciales de procesos, memoria, interrupciones, entrada/salida, seguridad y comunicación. Los controladores adaptan esos mecanismos a dispositivos concretos. Las bibliotecas del sistema ofrecen API de nivel superior. Los servicios o demonios ejecutan funciones persistentes, como registro, red, sincronización horaria o impresión. El intérprete de órdenes y la interfaz gráfica permiten administrar y usar el sistema, pero no constituyen por sí solos el sistema operativo.

2.4. Modelos de núcleo

En un núcleo monolítico, gran parte de los servicios esenciales se ejecuta en el mismo espacio privilegiado. Puede ofrecer gran rendimiento, pero un defecto en un componente privilegiado tiene amplio impacto. Linux se clasifica habitualmente como monolítico modular: permite cargar y descargar módulos, aunque estos operan con privilegios del núcleo. En un micronúcleo, se conserva en el núcleo un conjunto reducido de mecanismos y otros servicios se ejecutan como procesos separados, favoreciendo aislamiento y modularidad a costa de comunicaciones adicionales.

Los núcleos híbridos combinan ideas de ambos enfoques. La clasificación ayuda a comprender decisiones arquitectónicas, pero no debe usarse como juicio automático de calidad. Rendimiento, seguridad y mantenibilidad dependen de la implementación concreta, de las interfaces, del modelo de controladores y de la disciplina de desarrollo.

2.5. Modo usuario y modo núcleo

El procesador ofrece niveles de privilegio. Las aplicaciones ordinarias se ejecutan en modo usuario: no pueden modificar directamente tablas de páginas, deshabilitar interrupciones ni acceder libremente a dispositivos. El núcleo opera en modo privilegiado. Las transiciones se producen por llamadas al sistema, interrupciones y excepciones. Una excepción por división entre cero o acceso inválido no es un «mensaje del antivirus», sino un evento de ejecución que el sistema gestiona conforme a su política.

2.6. Interfaz, ABI y portabilidad

Una API describe cómo invoca una aplicación servicios de una biblioteca o plataforma. Una ABI concreta detalles binarios: convenciones de llamada, formato de ejecutables, tamaños de datos y uso de registros. Dos sistemas pueden ofrecer interfaces conceptualmente parecidas sin ser binariamente compatibles. La portabilidad puede conseguirse a nivel de código fuente mediante estándares, a nivel binario mediante una ABI estable o a nivel de ejecución mediante máquinas virtuales, runtimes o contenedores.

3. PROCESOS, HILOS, PLANIFICACIÓN Y COMUNICACIÓN

3.1. Proceso y contexto

Un programa es una representación pasiva de instrucciones y datos; un proceso es una instancia en ejecución. El sistema mantiene para cada proceso un bloque de control con identificador, estado, prioridad, credenciales, registros, contador de programa, mapa de memoria, ficheros abiertos, estadísticas y relaciones con otros procesos. El cambio de una tarea a otra requiere guardar y restaurar parte de ese contexto.

Los estados básicos son nuevo, listo, en ejecución, bloqueado o en espera y terminado. Un proceso listo dispone de los recursos necesarios salvo la CPU; uno bloqueado espera un evento, como la finalización de una entrada/salida, una señal o un dato. Esta distinción aparece con frecuencia en preguntas tipo test.

3.2. Hilos

Un hilo es una unidad de ejecución dentro de un proceso. Los hilos del mismo proceso comparten normalmente código, datos y ficheros abiertos, pero mantienen pila, registros y contador de programa propios. El multihilo reduce ciertos costes de creación y comunicación, aunque introduce riesgos de carrera, interbloqueo y corrupción de estado compartido.

Concurrencia significa que varias actividades progresan durante un intervalo; paralelismo significa que se ejecutan simultáneamente en distintos recursos de cómputo. En un único procesador puede existir concurrencia por reparto temporal sin paralelismo físico. En equipos multinúcleo puede existir paralelismo real, condicionado por dependencias, sincronización y capacidad del software para dividir el trabajo.

3.3. Planificación de CPU

El planificador selecciona una entidad ejecutable. Los criterios pueden incluir prioridad, equidad, tiempo de respuesta, caudal, plazos, afinidad y consumo. Entre los algoritmos didácticos se encuentran FCFS, trabajo más corto, prioridades y round robin. Los sistemas generales modernos emplean políticas más complejas y múltiples clases de planificación.

La planificación preventiva permite retirar la CPU a una tarea; la no preventiva espera a que la tarea ceda o se bloquee. La prevención mejora respuesta e interactividad, pero requiere sincronización y cambios de contexto. En tiempo real, «prioridad» no significa simplemente importancia humana: se combina con políticas y garantías temporales. Un sistema de tiempo real se caracteriza por cumplir restricciones de plazo, no por ejecutar siempre más rápido.

3.4. Sincronización y exclusión mutua

Cuando varias tareas acceden a un recurso compartido, el resultado puede depender del orden de ejecución. Una condición de carrera aparece cuando la corrección depende de una intercalación no controlada. Mutex, semáforos, monitores, variables de condición y operaciones atómicas coordinan acceso. El objetivo no es bloquear indiscriminadamente, sino proteger secciones críticas manteniendo progreso y rendimiento.

Un interbloqueo puede producirse cuando varias tareas esperan circularmente recursos retenidos por las demás. Las condiciones clásicas son exclusión mutua, retención y espera, ausencia de expulsión y espera circular. Los sistemas pueden prevenir, evitar, detectar y recuperar, o aceptar el riesgo cuando el coste de otro enfoque es mayor.

3.5. Comunicación entre procesos

La IPC incluye tuberías, colas de mensajes, memoria compartida, señales, sockets y llamadas remotas. La memoria compartida puede ser rápida, pero necesita sincronización. Los mensajes facilitan aislamiento, aunque añaden copia, serialización y gestión de colas. Los sockets permiten comunicación local o por red y constituyen una abstracción fundamental para arquitecturas distribuidas.

3.6. Creación y terminación

En sistemas tipo Unix, la creación suele explicarse mediante la separación conceptual entre duplicar un proceso y reemplazar su imagen ejecutable. En Windows, la API crea el proceso y su hilo inicial mediante otra semántica. Estas diferencias importan al portar software. La terminación libera recursos, comunica un estado y puede generar información diagnóstica. Un proceso huérfano, un proceso zombi y un servicio bloqueado representan problemas distintos y requieren herramientas diferentes.

4. GESTIÓN DE MEMORIA

4.1. Objetivos

La gestión de memoria debe localizar datos e instrucciones, asignar espacio, proteger procesos, compartir regiones de forma controlada y aprovechar la memoria disponible. Los programas trabajan con direcciones virtuales; la unidad de gestión de memoria y el sistema operativo las traducen a memoria física mediante estructuras como tablas de páginas.

4.2. Memoria virtual y paginación

La memoria virtual divide el espacio de direcciones en páginas y la memoria física en marcos. Una página puede estar residente, ausente, compartida, protegida contra escritura o asociada a un fichero. Si un proceso accede a una página válida que no está residente, se produce un fallo de página; el núcleo obtiene el contenido, actualiza las tablas y reanuda la ejecución. No todo fallo de página es un error: muchos forman parte del funcionamiento normal de la carga bajo demanda.

La TLB conserva traducciones recientes para reducir el coste de recorrer tablas. El tamaño de página influye en fragmentación, número de entradas y eficiencia de la TLB. Las páginas de gran tamaño pueden beneficiar determinadas cargas, pero no son una mejora universal. Deben evaluarse con métricas reales.

4.3. Sustitución, presión y paginación a almacenamiento

Cuando escasea memoria física, el sistema recupera páginas limpias o escribe páginas modificadas en un área de respaldo. La swap no «convierte el disco en RAM» con prestaciones equivalentes. Su latencia es mucho mayor y un uso intenso puede producir thrashing, situación en la que el sistema dedica excesivo tiempo a mover páginas y poco a ejecutar trabajo útil.

La memoria disponible no debe evaluarse solo por la cifra «libre». Los sistemas aprovechan RAM como caché de páginas y pueden recuperarla. Para diagnosticar presión hay que correlacionar actividad de paginación, fallos mayores, latencia de almacenamiento, conjunto residente, colas de CPU y comportamiento de la aplicación.

4.4. Protección y compartición

Las páginas incluyen permisos de lectura, escritura y ejecución. La política W^X intenta evitar que una región sea simultáneamente escribible y ejecutable. La memoria compartida permite IPC y bibliotecas compartidas, pero debe mapearse con permisos y ciclos de vida correctos. Técnicas como ASLR dificultan predecir posiciones de código y datos, aunque no sustituyen la corrección del software.

4.5. Errores de acceso

Una referencia a una dirección no mapeada o sin permisos genera una excepción. En sistemas tipo Unix suele traducirse en una señal como SIGSEGV. El comportamiento por defecto puede terminar el proceso y producir un volcado para diagnóstico. Un puntero nulo puede causar ese resultado, pero no es la única causa; también lo producen accesos fuera de límites, uso posterior a liberación o escrituras en páginas de solo lectura.

4.6. Asignación de memoria del núcleo y de usuario

Los gestores de memoria de usuario solicitan regiones al sistema y administran bloques para las aplicaciones. Fragmentación interna, fragmentación externa, alineación y patrones de asignación afectan al consumo. En el núcleo se emplean mecanismos especializados para objetos y páginas. Una fuga de memoria no siempre se debe al sistema operativo: puede originarse en la aplicación, una biblioteca, un controlador o una caché sin límite.

4.7. NUMA y afinidad

En arquitecturas NUMA, la latencia de acceso depende de la relación entre CPU y banco de memoria. El sistema intenta colocar memoria cerca de los procesadores que la usan y equilibrar la carga. Fijar afinidades sin comprender la topología puede empeorar el rendimiento. En virtualización, la topología presentada a la máquina virtual y la asignación física del hipervisor deben considerarse conjuntamente.

5. ENTRADA/SALIDA, DISPOSITIVOS Y SISTEMAS DE FICHEROS

5.1. Controladores, interrupciones y DMA

Los dispositivos exponen funciones mediante controladores. El núcleo coordina solicitudes, colas, interrupciones y errores. Con sondeo, la CPU consulta repetidamente el estado; con interrupciones, el dispositivo notifica un evento. El acceso directo a memoria, DMA, permite transferir bloques con intervención limitada de la CPU. Los sistemas modernos combinan interrupciones, agrupación, colas y operaciones asíncronas para reducir sobrecarga.

5.2. Abstracciones de entrada/salida

Descriptores, manejadores, flujos y sockets uniforman operaciones sobre objetos distintos. Una aplicación abre, lee, escribe, espera y cierra sin conocer todos los detalles físicos. El sistema aplica buffering y caché. La escritura que una aplicación considera completada puede estar en memoria y no en soporte persistente; por ello existen operaciones de sincronización, barreras y protocolos de recuperación.

5.3. Sistemas de ficheros

Un sistema de ficheros organiza nombres, directorios, metadatos, bloques, permisos y consistencia. FAT, NTFS, ReFS, ext4, XFS, Btrfs, APFS y otros responden a diseños y casos de uso diferentes. La elección debe considerar tamaño de volúmenes y ficheros, recuperación, instantáneas, cifrado, cuotas, compatibilidad, herramientas, soporte y carga prevista.

El journaling registra información que permite recuperar coherencia estructural tras una interrupción. No garantiza que el contenido lógico de todos los ficheros sea el esperado ni reemplaza una copia de seguridad. Los sistemas copy-on-write escriben nuevas versiones de bloques antes de actualizar referencias y facilitan instantáneas, pero exigen comprender fragmentación, amplificación de escritura y comportamiento ante capacidad baja.

5.4. Nombres, enlaces y metadatos

El nombre visible no es necesariamente el identificador interno. Los enlaces duros y simbólicos tienen semánticas distintas. Los metadatos incluyen propietario, grupo, tiempos, atributos y listas de control. En entornos compartidos, permisos de directorio, herencia, máscara de creación y ACL determinan el acceso efectivo. Las diferencias entre mayúsculas y minúsculas, caracteres permitidos y rutas máximas pueden bloquear migraciones.

5.5. Almacenamiento lógico

Particiones, volúmenes lógicos, espacios de almacenamiento y sistemas RAID separan el almacenamiento físico de la presentación al sistema de ficheros. LVM permite agrupar dispositivos y crear volúmenes redimensionables. RAID puede aportar rendimiento o tolerancia a determinados fallos de disco, pero no protege frente a borrado, corrupción lógica, credenciales comprometidas o desastre del emplazamiento.

5.6. Montaje y disponibilidad

Montar asocia un sistema de ficheros a un punto del espacio de nombres. Un montaje remoto añade dependencias de red, autenticación y servidor. Si un proceso queda bloqueado esperando un recurso remoto, el síntoma puede parecer un problema local de CPU o aplicación. La administración debe observar latencia, errores, tiempo de espera y semántica de reintento.

5.7. Copias, instantáneas y consistencia de aplicaciones

Una instantánea captura un estado lógico rápido, a menudo dependiente del mismo almacenamiento. Una copia de seguridad crea una copia recuperable conforme a una política y debe protegerse frente al fallo o compromiso del origen. Para bases de datos y aplicaciones con estado, la consistencia requiere coordinación: quiescencia, agentes, registros de transacciones o procedimientos específicos. Restaurar es la prueba real; una tarea de copia finalizada sin error no demuestra recuperabilidad.

6. PROTECCIÓN, SEGURIDAD, AUDITORÍA Y OBSERVABILIDAD

6.1. Identificación, autenticación y autorización

El sistema operativo representa identidades mediante cuentas y, en muchos casos, identificadores numéricos o de seguridad. La autenticación demuestra una identidad; la autorización decide qué puede hacer; la auditoría registra acciones relevantes. Compartir cuentas administrativas destruye trazabilidad. El principio de mínimo privilegio exige conceder solo las capacidades necesarias, durante el tiempo necesario y con controles reforzados para tareas críticas.

6.2. Control discrecional y obligatorio

El control de acceso discrecional permite que el propietario o una autoridad definida modifique permisos. Las ACL expresan reglas más detalladas que los bits básicos. El control obligatorio, como SELinux, aplica políticas de seguridad que no dependen únicamente de la decisión del propietario. Los mecanismos pueden coexistir: una operación debe superar todas las comprobaciones aplicables.

6.3. Arranque y cadena de confianza

El arranque seguro verifica componentes antes de transferirles control. Una raíz de confianza anclada en hardware valida firmware, cargador, núcleo y componentes posteriores. La verificación de integridad reduce la posibilidad de ejecutar código alterado, pero necesita gestión de claves, actualización segura y procedimientos de recuperación. Un equipo con arranque seguro no queda protegido automáticamente frente a credenciales robadas o aplicaciones maliciosas autorizadas por el usuario.

6.4. Cifrado

El cifrado de volumen protege datos en reposo frente a pérdida o extracción del soporte, siempre que las claves estén protegidas. BitLocker, LUKS y mecanismos de protección de datos móviles son ejemplos. El cifrado no impide que un usuario autenticado o un malware con acceso al sistema lea datos ya desbloqueados. Debe combinarse con control de acceso, bloqueo, gestión de claves, copia de recuperación y respuesta ante incidentes.

6.5. Actualización y vulnerabilidades

La gestión de parches inventaría versiones, evalúa aplicabilidad y riesgo, prueba, despliega por anillos, verifica y conserva capacidad de reversión. «Aplicar todo inmediatamente» y «no actualizar nunca» son extremos inadecuados. La urgencia depende de exposición, explotación conocida, criticidad, controles compensatorios y riesgo de interrupción. Los sistemas fuera de soporte acumulan riesgo porque dejan de recibir correcciones ordinarias.

6.6. Registro y auditoría

Los registros de sistema, seguridad, aplicación y acceso permiten reconstruir eventos. Deben tener hora sincronizada, origen identificable, retención definida, protección frente a alteración y capacidad de búsqueda. El volumen de logs no equivale a observabilidad. Es necesario seleccionar eventos, correlacionar, establecer alertas y documentar qué evidencia se espera ante un incidente.

6.7. Observabilidad y salud

Las señales básicas son métricas, registros y trazas. En el sistema operativo se observan uso y saturación de CPU, presión de memoria, fallos de página, colas y latencias de E/S, errores de disco, conexiones, pérdida de paquetes, procesos, servicios y reinicios. Una media de CPU moderada puede ocultar un único núcleo saturado; un disco con porcentaje de uso alto puede ser normal o indicar cuello de botella según latencia y cola.

6.8. Endurecimiento

El hardening reduce superficie de ataque: desinstalar o deshabilitar funciones no necesarias, cerrar puertos, limitar administración remota, reforzar autenticación, aplicar políticas, proteger secretos, configurar auditoría y validar integridad. Debe expresarse como una línea base versionada, no como cambios manuales indocumentados. Una línea base demasiado rígida puede romper funciones; por eso se prueba y se gestionan excepciones.

7. EVOLUCIÓN Y TENDENCIAS DE LOS SISTEMAS OPERATIVOS

7.1. Procesamiento por lotes

Los primeros computadores ejecutaban trabajos preparados de antemano. El operador agrupaba programas y datos, y el sistema encadenaba fases con poca interacción. El objetivo principal era aumentar utilización de equipos costosos y reducir tiempos muertos entre trabajos. Aparecieron monitores residentes, control de trabajos y mecanismos iniciales de entrada/salida.

7.2. Multiprogramación y tiempo compartido

La multiprogramación mantuvo varios trabajos en memoria para aprovechar la CPU mientras uno esperaba entrada/salida. El tiempo compartido añadió interacción y reparto rápido de CPU entre usuarios. Esto impulsó planificación preventiva, protección de memoria, terminales, sistemas de ficheros multiusuario y contabilidad de recursos. Multics y Unix son referencias históricas por sus ideas de protección, jerarquía de ficheros, procesos y herramientas componibles.

7.3. Minicomputadores, Unix y portabilidad

La reimplementación de gran parte de Unix en C facilitó su adaptación a distintas máquinas. Surgieron familias y variantes con diferencias de interfaz y administración. La necesidad de portabilidad favoreció estándares de interfaces, lenguajes y utilidades. La filosofía de herramientas pequeñas conectadas mediante flujos influyó en shells, automatización y diseño de servicios.

7.4. Ordenador personal e interfaz gráfica

La expansión del PC trasladó el foco hacia facilidad de uso, compatibilidad de periféricos y aplicaciones de escritorio. Los primeros sistemas personales tenían protección y multitarea limitadas. La evolución hacia Windows NT, macOS basado en Darwin y otros sistemas modernos incorporó separación de procesos, memoria virtual, seguridad multiusuario y redes como capacidades centrales, aunque la experiencia de usuario siguió siendo determinante.

7.5. Sistemas distribuidos y redes

La conectividad convirtió la red en parte ordinaria del sistema operativo. Se integraron pilas TCP/IP, servicios de nombres, autenticación distribuida, compartición de ficheros, administración remota y sincronización horaria. El sistema dejó de ser una máquina aislada y pasó a participar en dominios, clústeres y servicios corporativos. La identidad y la resolución de nombres se convirtieron en dependencias de primer nivel.

7.6. Virtualización

La virtualización separa la máquina lógica del hardware físico. Un hipervisor asigna CPU, memoria y dispositivos virtuales, permite consolidación, movilidad y aprovisionamiento rápido. No elimina la administración del sistema operativo invitado: cada máquina mantiene parches, cuentas, servicios, almacenamiento y registros. La facilidad para crear máquinas puede generar proliferación, configuraciones inconsistentes y sistemas olvidados.

7.7. Cloud y automatización

En infraestructura como servicio, el sistema operativo sigue siendo responsabilidad del consumidor en aspectos como configuración, parches, identidades y aplicaciones, aunque el proveedor gestione hardware y capa de virtualización. Las imágenes, plantillas e infraestructura como código desplazan la práctica desde la configuración manual hacia la declaración reproducible. La máquina deja de ser un «servidor artesanal» y se trata como una instancia reemplazable dentro de un servicio.

7.8. Contenedores

Los contenedores aíslan procesos mediante funciones del núcleo, como espacios de nombres y control de recursos, pero comparten el kernel del host. Su imagen empaqueta aplicación y dependencias de espacio de usuario. Son más ligeros que una máquina virtual completa, aunque el aislamiento y el modelo de seguridad son distintos. El sistema operativo del nodo, el runtime y el orquestador siguen siendo componentes críticos.

7.9. Sistemas inmutables y actualizaciones atómicas

Una tendencia es reducir cambios interactivos en producción. El sistema se construye como imagen, se valida y se despliega de forma reproducible. Las actualizaciones atómicas permiten cambiar entre estados completos y facilitar reversión. Esto reduce deriva de configuración, pero exige separar datos persistentes, externalizar secretos y diseñar observabilidad y recuperación.

7.10. Edge, IoT y tiempo real

Los sistemas de borde procesan cerca de la fuente para reducir latencia o dependencia de conectividad. En IoT importan consumo, arranque, actualizaciones remotas y seguridad del ciclo de vida. Un RTOS prioriza determinismo y plazos; un sistema general prioriza flexibilidad y caudal. En equipamiento sanitario o industrial, la certificación y soporte del fabricante limitan cambios que serían habituales en un servidor general.

7.11. Seguridad por diseño y hardware de confianza

TPM, enclaves, arranque verificado, firma de código, cifrado y aislamiento por hardware se integran en plataformas actuales. La seguridad se desplaza hacia cadenas de confianza y medición de estado. También crece la adopción de arquitecturas de confianza cero: la ubicación en una red interna no basta para autorizar; se evalúan identidad, dispositivo, cumplimiento y contexto.

7.12. Inteligencia artificial y administración asistida

La IA se incorpora a detección de anomalías, clasificación de eventos, asistencia de comandos y optimización. Sin embargo, una recomendación generada no sustituye controles de cambio, revisión ni evidencia. En producción, cualquier acción automática debe respetar permisos, límites, trazabilidad y reversión. El riesgo no está solo en una respuesta incorrecta, sino en ejecutar una respuesta correcta en el sistema equivocado o con un alcance excesivo.

8. SISTEMAS ABIERTOS, CÓDIGO ABIERTO Y SISTEMAS PROPIETARIOS

8.1. Sistema abierto

Un sistema abierto se apoya en especificaciones públicas y estables que facilitan interoperabilidad, portabilidad y sustitución de componentes. La apertura puede referirse a API, protocolos, formatos, interfaces de administración o compatibilidad con estándares. Un producto propietario puede implementar estándares abiertos, y un producto con código disponible puede usar extensiones no interoperables.

POSIX define un entorno e interfaces de sistema operativo, shell y utilidades comunes. Su finalidad es favorecer portabilidad de aplicaciones a nivel de fuente. No garantiza que dos sistemas sean idénticos ni que cualquier binario funcione sin recompilar. También existen estándares de lenguajes, red, seguridad y formatos que contribuyen a la apertura del ecosistema.

8.2. Código abierto

El software de código abierto se distribuye bajo licencias que permiten acceso al código y determinados derechos de uso, estudio, modificación y redistribución. Las obligaciones varían. Licencias copyleft pueden exigir mantener la licencia al distribuir obras derivadas; licencias permisivas imponen menos condiciones. «Código abierto» no significa necesariamente ausencia de coste, garantía, soporte o restricciones de marca.

8.3. Sistema propietario

En un sistema propietario, el fabricante controla código, licencia, evolución y condiciones de distribución. Puede ofrecer soporte integrado, certificaciones, herramientas coherentes y amplia compatibilidad con su ecosistema. A cambio, la organización depende en mayor grado de decisiones de producto, licenciamiento, formatos y ciclos de soporte del proveedor.

8.4. Comparación razonada

8.5. Coste total de propiedad

El TCO incluye licencias, suscripciones, hardware, implantación, migración, formación, personal, soporte, monitorización, seguridad, indisponibilidad, renovación y retirada. La ausencia de precio de licencia no implica coste cero. Una solución con licencia puede resultar más económica si reduce integración o soporte; una abierta puede ser preferible si mejora automatización, portabilidad o competencia entre proveedores.

8.6. Riesgo de dependencia

El lock-in aparece cuando cambiar tiene un coste desproporcionado por formatos, API, habilidades, contratos, identidad, datos o procesos. No se evita únicamente eligiendo código abierto. Se reduce con estándares, exportación probada, documentación, automatización portable, separación de datos y aplicación, cláusulas de salida y pruebas periódicas de recuperación o migración.

8.7. Criterios de selección en el sector público sanitario

• Compatibilidad funcional y certificación de aplicaciones y dispositivos.
• Soporte durante la vida prevista y disponibilidad de actualizaciones de seguridad.
• Integración con identidad, red, monitorización, copias y operación corporativa.
• Capacidad para cumplir políticas de seguridad, protección de datos y continuidad.
• Automatización, administración remota y gestión a escala.
• Mercado de profesionales y proveedores, documentación y transferencia de conocimiento.
• TCO, riesgo contractual y estrategia de salida.

9. ADMINISTRACIÓN Y GESTIÓN DEL SISTEMA OPERATIVO

9.1. Administración como proceso continuo

Administrar un sistema operativo consiste en mantener un estado controlado durante todo su ciclo de vida. La actividad comienza antes de instalar: se definen finalidad, propietario, criticidad, clasificación de información, requisitos, dependencias y soporte. Termina cuando se retiran datos, credenciales, certificados, registros y activos de inventario.

9.2. Inventario y configuración

El inventario debe identificar equipo, versión, edición, arquitectura, ubicación, propietario, función, red, aplicaciones, dependencias, estado de soporte y línea base. Una CMDB puede relacionar elementos, pero su valor depende de actualización y uso. La gestión de configuración define el estado autorizado y detecta deriva. Cambios fuera de control generan sistemas únicos difíciles de recuperar.

9.3. Identidades y privilegios

Las cuentas se crean, modifican, revisan y eliminan mediante un ciclo de vida. Las cuentas de servicio deben tener propietario, propósito, permisos mínimos, rotación o gestión de secretos y restricciones de inicio. La administración privilegiada debe usar cuentas separadas, autenticación reforzada, estaciones seguras y registro. Las cuentas inactivas y credenciales incrustadas son riesgos frecuentes.

9.4. Software y parches

La gestión de paquetes e instalaciones controla origen, firma, versión y dependencias. Las actualizaciones se agrupan en anillos: laboratorio, piloto, producción no crítica y crítica. Se definen ventanas, reinicios, validaciones y criterios de retirada. En clústeres o granjas se actualiza preservando capacidad. Un parche aplicado pero no activado por reinicio puede dejar una falsa sensación de protección.

9.5. Capacidad y rendimiento

La capacidad se gestiona con tendencias y umbrales. CPU, memoria, almacenamiento y red se relacionan con demanda y niveles de servicio. Debe evitarse la saturación, pero también el sobredimensionamiento sistemático. La planificación usa percentiles, picos, crecimiento, estacionalidad y margen. La media mensual rara vez basta para una aplicación con picos asistenciales.

9.6. Disponibilidad y continuidad

La alta disponibilidad reduce interrupciones mediante redundancia, detección y conmutación. La recuperación ante desastres restaura servicio tras pérdida mayor. El sistema operativo participa en clústeres, replicación, arranque, servicios y automatización, pero la continuidad debe abarcar datos, identidad, red, aplicación, procedimientos y personas.

9.7. Copia y recuperación

La política define qué se copia, frecuencia, retención, ubicación, cifrado, inmutabilidad y pruebas. RPO expresa pérdida máxima de datos tolerable; RTO, tiempo objetivo de recuperación. Una imagen completa acelera reconstrucción, mientras que la restauración granular recupera objetos concretos. Las configuraciones y claves deben respaldarse con el mismo rigor que los datos.

9.8. Incidencias y problemas

La respuesta a una incidencia prioriza restaurar servicio de forma segura, conservar evidencia y comunicar impacto. El análisis de problemas busca causa raíz y prevención. Reiniciar puede recuperar temporalmente, pero elimina síntomas y evidencia si se hace sin capturar estado. Un buen procedimiento recoge hora, cambios, métricas, logs, procesos, conexiones y acciones ejecutadas.

9.9. Cambios y documentación

Todo cambio significativo debe tener objetivo, alcance, evaluación de riesgo, prueba, validación, ventana y plan de reversión. La documentación útil incluye estado as-built, diagramas, procedimientos, dependencias, responsables, credenciales referenciadas de forma segura y criterios de escalado. Una instrucción que solo conoce una persona no es un procedimiento operativo.

9.10. Automatización

La automatización reduce variabilidad y permite repetir. Debe ser idempotente cuando sea posible: ejecutar de nuevo conduce al mismo estado deseado. Código, plantillas e inventarios se versionan y revisan. Automatizar un proceso defectuoso amplifica el error; por ello se incorporan validaciones, límites, modo simulación, aprobación y reversión.

10. ADMINISTRACIÓN DE SISTEMAS UNIX Y LINUX

10.1. Identidades, grupos y permisos

Linux usa identificadores numéricos de usuario y grupo. Los nombres son representaciones legibles resueltas mediante fuentes locales o servicios de identidad. El UID 0 posee privilegios de superusuario. Los objetos almacenan UID y GID; si se reutiliza un identificador, el nuevo nombre puede aparecer como propietario de objetos antiguos. La unicidad y el ciclo de vida de UID deben gestionarse.

Los permisos clásicos se expresan para propietario, grupo y otros. Lectura, escritura y ejecución tienen significado dependiente del objeto; en un directorio, ejecución permite atravesarlo. ACL añade entradas específicas. chmod cambia permisos; chown, propietario o grupo de ficheros; no «cambia el UID de un proceso en memoria».

id usuario
getent passwd usuario
ls -l /ruta
namei -l /ruta/al/objeto
getfacl /ruta/objeto
setfacl -m u:usuario:rw /ruta/objeto

10.2. Elevación de privilegios

sudo autoriza ejecutar comandos como otro usuario conforme a una política. Normalmente autentica al usuario invocante, aunque la configuración puede permitir ejecución sin contraseña, usar caché temporal o exigir otros mecanismos. La ventaja es no compartir la contraseña de root y registrar quién solicitó la operación. El fichero de política debe editarse con herramientas que validen sintaxis.

10.3. Procesos y señales

ps ofrece una instantánea; top muestra actividad; pgrep localiza procesos; kill envía señales. SIGTERM solicita terminación ordenada; SIGKILL no puede interceptarse y debe reservarse para procesos que no responden. La prioridad se expresa mediante valores nice y políticas del planificador.

ps -eo pid,ppid,user,stat,ni,%cpu,%mem,cmd --sort=-%cpu
pgrep -a nombre
kill -TERM 1234
renice 5 -p 1234
ulimit -a

10.4. Servicios y arranque

En muchas distribuciones actuales, systemd coordina unidades y dependencias. systemctl consulta, inicia, detiene, habilita y enmascara. Habilitar afecta al arranque; iniciar cambia el estado actual. journalctl consulta el diario. Deben revisarse causa, código de salida, dependencias y límites antes de reiniciar repetidamente.

systemctl status servicio
systemctl list-dependencies servicio
systemctl enable --now servicio
journalctl -u servicio --since "-1 hour"
journalctl -p warning..alert -b

10.5. Tareas programadas

cron ejecuta tareas según calendario. El entorno es más limitado que una sesión interactiva: ruta, variables, usuario y directorio deben declararse. Los temporizadores de systemd ofrecen dependencias, persistencia y registro integrados. Una tarea programada debe evitar solapamientos no deseados, registrar resultado y gestionar errores.

10.6. Paquetes

Las familias Debian y RPM emplean gestores distintos. El administrador debe usar repositorios autorizados, validar firmas y controlar versiones. Instalar manualmente desde fuentes puede dificultar inventario, actualización y retirada. En entornos críticos, se mantienen repositorios internos o espejos para reproducibilidad y control.

# Debian/Ubuntu
apt update
apt list --upgradable
apt install paquete

# RHEL y derivados
dnf check-update
dnf install paquete
dnf history

10.7. Red

La administración incluye direcciones, rutas, DNS, filtros y sockets. ip sustituye a utilidades históricas en muchas tareas; ss consulta sockets; resolvectl puede mostrar resolución en sistemas que usan systemd-resolved. Una prueba debe separar conectividad IP, ruta, puerto, TLS, nombre y aplicación.

ip address show
ip route show
ss -lntup
resolvectl status
curl -vk https://servidor/

10.8. Almacenamiento y ficheros

lsblk, blkid, df y du responden preguntas diferentes. df informa del sistema de ficheros; du, de bloques asociados a rutas. Un fichero borrado pero abierto puede consumir espacio sin aparecer en el árbol. LVM, RAID y montajes requieren documentación y prueba de arranque.

lsblk -f
df -hT
du -xhd1 /var | sort -h
lsof +L1
findmnt

10.9. Seguridad y registros

SELinux o AppArmor complementan permisos. Cambiar a modo permisivo puede demostrar que una política interviene, pero no es solución permanente. Se revisan contextos, eventos y reglas mínimas. La administración remota por SSH debe limitar algoritmos, credenciales, origen, privilegios y registro.

11. ADMINISTRACIÓN DE SISTEMAS WINDOWS

11.1. Identidad y seguridad

Windows usa identificadores de seguridad, SID, para cuentas y grupos. El nombre puede cambiar sin alterar el SID. Las ACL de objetos contienen entradas de control asociadas a SID. En dominio, Active Directory centraliza identidad, grupos, equipos y políticas. El acceso efectivo depende de token, pertenencias, herencia, denegaciones, privilegios y condiciones.

11.2. Servicios y procesos

El Service Control Manager administra servicios. Cada servicio tiene identidad, tipo de inicio, dependencias y recuperación. Ejecutar todos con cuentas de alto privilegio aumenta impacto. PowerShell permite consultar y modificar de forma reproducible; el Administrador de tareas y Monitor de recursos ofrecen vista interactiva.

Get-Service | Sort-Object Status,Name
Get-Service -Name w32time
Get-CimInstance Win32_Service | Select-Object Name,StartName,State,StartMode
Restart-Service -Name w32time
Get-Process | Sort-Object CPU -Descending | Select-Object -First 10

11.3. Eventos

El Visor de eventos organiza registros de sistema, seguridad, aplicaciones y canales específicos. El identificador de evento necesita contexto: proveedor, versión, nivel, equipo y correlación. PowerShell facilita filtros. El reenvío de eventos centraliza evidencia, pero requiere capacidad, retención y protección.

Get-WinEvent -LogName System -MaxEvents 50
Get-WinEvent -FilterHashtable @{LogName='System'; Level=2; StartTime=(Get-Date).AddHours(-4)}

11.4. Red y puertos

Get-NetTCPConnection y netstat permiten observar puertos y conexiones. Un puerto en escucha demuestra que un proceso ha abierto un socket local, no que el servicio sea accesible desde otra red ni que responda correctamente. Firewall, ruta, NAT, TLS y aplicación deben verificarse por separado.

Get-NetTCPConnection -State Listen | Sort-Object LocalPort
Get-NetIPConfiguration
Test-NetConnection servidor -Port 443
netstat -ano

11.5. Roles, características y administración remota

Windows Server separa roles y características. Server Manager, PowerShell y Windows Admin Center permiten administración local y remota. Server Core reduce componentes gráficos y superficie, pero exige que aplicaciones y equipo sean compatibles con ese modelo. La administración remota debe protegerse con autenticación, cifrado, segmentación y privilegios mínimos.

11.6. Directiva de grupo

Las GPO aplican configuraciones de equipo y usuario conforme a ámbito y precedencia. Deben diseñarse con unidades organizativas, filtrado, pruebas y documentación. Una directiva demasiado amplia puede afectar miles de puestos. Las políticas no reemplazan inventario ni control de excepciones.

11.7. Actualizaciones y ciclo de vida

Las actualizaciones se gestionan mediante servicios corporativos y políticas de mantenimiento. En servidores, se coordinan con roles, clústeres y ventanas. La ruta de actualización admitida depende de versión, edición, rol y configuración. Migrar un rol a un servidor nuevo puede ser preferible a una actualización sobre el mismo equipo, porque permite limpiar dependencias y facilita reversión.

11.8. Cifrado y protección de credenciales

BitLocker cifra volúmenes y puede proteger claves mediante TPM, PIN y recuperación. La organización debe custodiar las claves de recuperación. Otras funciones protegen credenciales, integridad y aplicaciones. La activación debe verificarse; no basta con que la política exista.

11.9. Automatización con PowerShell

PowerShell trabaja con objetos, no solo texto. Los cmdlets siguen verbos y nombres. El pipeline conserva propiedades y tipos. Los scripts deben usar gestión de errores, registros, parámetros y modo de simulación cuando exista. La firma y política de ejecución son controles, pero no sustituyen revisión ni mínimo privilegio.

$ErrorActionPreference = 'Stop'
$service = Get-Service -Name 'w32time'
if ($service.Status -ne 'Running') {
    Start-Service -Name 'w32time'
}
Get-Service -Name 'w32time' | Select-Object Name,Status,StartType

12. PLANES DE IMPLANTACIÓN

12.1. Finalidad

Un plan de implantación transforma una decisión tecnológica en un servicio operable. Debe reducir incertidumbre, coordinar equipos y establecer evidencia para aceptar o rechazar el despliegue. No es una lista de pasos de instalación; incluye requisitos, arquitectura, seguridad, datos, soporte, comunicación, formación y continuidad.

12.2. Inicio y gobierno

Se define patrocinio, dirección, responsables técnicos y funcionales, alcance, exclusiones, centros afectados, usuarios, criticidad y criterios de éxito. Una matriz de responsabilidades evita lagunas entre infraestructura, comunicaciones, seguridad, aplicación, soporte, proveedores y unidades usuarias. También se define el proceso de decisiones, escalado y control de cambios.

12.3. Descubrimiento

El inventario recoge hardware, firmware, versiones, aplicaciones, controladores, periféricos, impresoras, certificados, red, identidades, scripts, tareas, datos y dependencias. Las entrevistas complementan herramientas automáticas porque muchas dependencias no aparecen en escaneos: macros, rutas compartidas, accesos ocasionales, dispositivos clínicos o procedimientos manuales.

12.4. Requisitos y compatibilidad

Los requisitos funcionales indican qué debe seguir funcionando. Los no funcionales incluyen rendimiento, disponibilidad, seguridad, privacidad, usabilidad, soporte y mantenibilidad. Se construye una matriz de compatibilidad con estados: soportado, soportado con cambio, requiere actualización, sustituible o bloqueante. Cada bloqueo tiene responsable y fecha.

12.5. Diseño objetivo

El diseño define versión, edición, arquitectura, particionado, cifrado, red, nombres, unión a dominio, administración, agentes, registros, copias, actualización y recuperación. También establece imagen maestra, secuencia de tareas, paquetes y perfiles. El diseño debe diferenciar configuración común y excepciones justificadas.

12.6. Línea base

La línea base describe el estado autorizado: servicios, puertos, usuarios, políticas, repositorios, software, parámetros y controles. Debe ser aplicable por automatización o comprobable por herramientas. Si solo existe como documento y no se verifica, la deriva aparecerá desde el primer día.

12.7. Laboratorio y piloto

El laboratorio valida técnica básica. El piloto prueba usuarios, aplicaciones, rendimiento, soporte, formación y procesos reales con alcance limitado. La muestra debe cubrir casos representativos, no solo usuarios expertos. Se definen métricas, incidencias aceptables y criterios go/no-go. Un piloto sin decisión formal se convierte en producción no controlada.

12.8. Estrategia de despliegue

El despliegue puede ser masivo, por fases, por centros, por perfiles o paralelo. El enfoque masivo reduce coexistencia, pero concentra riesgo. El faseado limita impacto y permite aprender, aunque prolonga compatibilidad dual. En puestos, se usan anillos; en servidores, granjas y redundancia permiten rotación si la aplicación la soporta.

12.9. Comunicación y formación

Los usuarios necesitan saber qué cambia, cuándo, qué deben conservar, cómo solicitar ayuda y qué incidencias son esperables. El soporte necesita guías, herramientas, permisos y base de conocimiento. Los administradores reciben formación de operación, no solo de instalación. La comunicación debe distinguir parada, degradación y cambio de interfaz.

12.10. Corte, validación y reversión

El plan de corte detalla secuencia, dependencias, tiempos, responsables y puntos de decisión. La validación incluye arranque, identidad, red, aplicaciones, datos, impresión, seguridad, monitorización y copia. La reversión debe ser ejecutable dentro de la ventana; «reinstalar el sistema anterior» no es un plan si no se han conservado imágenes, datos y configuraciones.

12.11. Estabilización y cierre

Tras desplegar se monitorizan incidencias, rendimiento y adopción. Se corrigen causas, se actualiza documentación y se transfiere a operación. El cierre retira elementos temporales y sistemas antiguos, revoca accesos, archiva evidencias y revisa resultados. Mantener indefinidamente la plataforma anterior aumenta coste y superficie de ataque.

13. PLANES Y ESTRATEGIAS DE MIGRACIÓN

13.1. Concepto

Migrar es trasladar cargas, datos, identidades o servicios desde un estado origen a otro destino manteniendo requisitos. Puede cambiar versión, hardware, arquitectura, sistema operativo, ubicación o modelo de operación. El objetivo no es copiar ficheros, sino conservar función, integridad, seguridad y continuidad.

13.2. Estrategias

13.3. Evaluación del origen

Se captura configuración, datos, cuentas, permisos, servicios, puertos, certificados, tareas, integraciones, rendimiento y errores conocidos. Debe registrarse una línea base para comparar. Una migración puede parecer correcta y, sin embargo, perder tareas mensuales, ACL poco usadas o integraciones activadas solo en contingencia.

13.4. Aplicaciones y dependencias

Se analizan binarios, arquitectura, runtimes, bibliotecas, drivers, protocolos, autenticación y soporte. Las dependencias pueden ser técnicas y contractuales. Una aplicación de 32 bits puede funcionar en un sistema de 64 bits mediante compatibilidad, pero un controlador de 32 bits no necesariamente. Los componentes en modo núcleo requieren especial atención.

13.5. Datos

La estrategia de datos define copia inicial, sincronización incremental, congelación, validación y custodia. La integridad se comprueba con recuentos, hashes, restricciones y pruebas funcionales. En sistemas transaccionales se debe evitar doble escritura incoherente. La fecha de corte y la autoridad del dato deben quedar claras.

13.6. Identidad y permisos

Los nombres visibles no bastan para conservar autorización. SID, UID, grupos, ACL, certificados y cuentas de servicio deben mapearse. Cambiar dominio, directorio o mecanismo de autenticación puede afectar aplicaciones que guardan identificadores. Se prueban acceso normal, administración, cuentas técnicas y escenarios de baja conectividad.

13.7. Prueba

Las pruebas cubren función, rendimiento, seguridad, recuperación y operación. Se ejecutan con datos representativos y una carga realista. La prueba de restauración debe realizarse en el destino. También se comprueba que monitorización, antivirus o EDR, copias y escáneres reconozcan el nuevo sistema.

13.8. Reversión

El rollback define hasta qué momento puede volver el servicio y qué ocurre con datos generados tras el corte. En una migración con escrituras, volver al origen puede implicar pérdida o reconciliación. La decisión debe tomarse antes de superar el punto de no retorno. Se asigna autoridad para declarar reversión.

13.9. Migración de Windows Server

La ruta admitida de actualización depende de versión y rol. Microsoft ofrece herramientas de migración de roles y servicios de migración de almacenamiento. Para controladores de dominio suele ser preferible incorporar servidores nuevos, promoverlos, transferir funciones, validar replicación y retirar los anteriores, en lugar de depender solo de una actualización del mismo sistema.

13.10. Migración Linux

Puede realizarse actualización de distribución o reconstrucción. Deben revisarse repositorios, paquetes, archivos de configuración, cambios de init, versiones de lenguaje, módulos de kernel, SELinux, nombres de interfaces y formato de logs. Copiar /etc completo sobre una versión nueva es peligroso porque mezcla sintaxis y valores obsoletos.

13.11. Criterios de aceptación

La aceptación debe ser medible: pruebas superadas, errores dentro de tolerancia, rendimiento no inferior al umbral, copias ejecutadas, restauración comprobada, eventos recibidos, seguridad validada, documentación entregada y soporte preparado. «Arranca» no es criterio suficiente.

14. INSTALACIÓN, CONFIGURACIÓN, ENDURECIMIENTO Y OPTIMIZACIÓN

14.1. Preparación

Antes de instalar se verifica soporte de hardware, firmware, arquitectura, capacidad, controladores y licencia. La imagen debe proceder de fuente autorizada y comprobarse mediante firma o hash. Se documentan versión y medio. En instalaciones automatizadas, la plantilla se versiona y prueba igual que código.

14.2. Arranque y firmware

UEFI inicializa hardware y localiza el cargador. Secure Boot valida componentes firmados según claves configuradas. La instalación debe decidir modo de arranque, particionado GPT, orden de dispositivos y protección del firmware. Cambiar posteriormente de modo puede impedir el arranque.

14.3. Particionado y almacenamiento

El diseño separa sistema, datos, logs y temporales cuando aporta recuperación, seguridad o control de capacidad. No existe un reparto universal. La swap, el tamaño de volúmenes y el sistema de ficheros dependen de carga y soporte. LVM o espacios de almacenamiento ofrecen flexibilidad, pero deben integrarse con copia y monitorización.

14.4. Instalación mínima

Se instalan solo roles y paquetes necesarios. Menos componentes reducen superficie y mantenimiento. En servidores se evita software de usuario no requerido. Tras instalar se aplican actualizaciones, controladores, hora, red, nombre, identidad, agentes y línea base antes de abrir el servicio.

14.5. Red

Se configuran dirección, máscara o prefijo, puerta de enlace, DNS, MTU si procede, VLAN y filtrado. El DNS corporativo debe usarse conforme a arquitectura; introducir servidores públicos en un equipo interno puede romper resolución y filtrar consultas. La sincronización horaria es crítica para autenticación, certificados, logs y aplicaciones distribuidas.

14.6. Configuración segura

La línea base deshabilita servicios, configura firewall, protege administración, aplica política de contraseñas y privilegios, habilita auditoría, cifra almacenamiento y restringe ejecución. Los secretos no se guardan en scripts ni imágenes. Se crea una cuenta de emergencia controlada y se prueba la recuperación de claves.

14.7. Instalación de aplicaciones

Las aplicaciones se ejecutan con cuentas dedicadas, rutas y permisos definidos. Se separan binarios, configuración, datos y logs. Se evita ejecutar como administrador o root cuando no es necesario. El servicio debe tener límites, dependencias, reinicio controlado y comprobación de salud.

14.8. Optimización basada en evidencia

Optimizar es mejorar un objetivo medible sin degradar otros requisitos. El proceso correcto es: establecer línea base, localizar cuello, formular hipótesis, cambiar un elemento, medir y documentar. Ajustar parámetros por recetas genéricas puede desplazar el problema. CPU, memoria, disco y red se analizan junto con la aplicación.

14.9. CPU

Se observan utilización por núcleo, cola, cambios de contexto, interrupciones, robos de CPU en virtualización y afinidad. Una CPU al 100 % puede indicar uso productivo o saturación. La cola sostenida y el aumento de latencia orientan. Aumentar prioridad puede perjudicar otros servicios y no elimina trabajo.

14.10. Memoria

Se revisan conjunto residente, compromiso, caché, paginación, fallos mayores, OOM y fugas. Añadir RAM ayuda si existe presión real; no corrige una fuga infinita. Reducir swappiness o desactivar paginación sin entender la carga puede aumentar riesgo de terminación por falta de memoria.

14.11. Entrada/salida

Se miden IOPS, caudal, latencia, cola y patrón. Una aplicación de muchas operaciones pequeñas tiene necesidades distintas a una transferencia secuencial. La caché puede ocultar el soporte. Deben revisarse alineación, controladores, políticas de escritura, sistema de ficheros y almacenamiento subyacente.

14.12. Red

Se distinguen ancho de banda, latencia, pérdida, retransmisiones, colas y resolución DNS. Aumentar buffers puede ayudar en enlaces de gran producto ancho de banda-retardo, pero también incrementar latencia. Cambiar MTU sin consistencia extremo a extremo provoca fallos sutiles.

14.13. Validación

La instalación se acepta con pruebas automatizadas y manuales: versión, parche, servicios, puertos, identidad, hora, almacenamiento, logs, copia, restauración, seguridad y rendimiento. Se guarda evidencia. Una imagen maestra se sella solo después de validar y eliminar identificadores o secretos que no deban clonarse.

15. HERRAMIENTAS, AUTOMATIZACIÓN Y MONITORIZACIÓN

15.1. Herramientas locales

Las utilidades de línea de comandos son esenciales porque permiten precisión, repetición y operación remota. En Linux destacan ps, top, ss, ip, journalctl, df, du, lsof, strace y herramientas específicas de rendimiento. En Windows, PowerShell, Event Viewer, Performance Monitor, Resource Monitor y Sysinternals cubren procesos, eventos, rendimiento y diagnóstico.

15.2. Administración remota

SSH, WinRM, PowerShell Remoting, consolas web y herramientas de gestión permiten escala. La administración remota debe usar canales cifrados, autenticación fuerte, segmentación, salto controlado y registro. Exponer interfaces administrativas directamente a redes no confiables es un riesgo grave.

15.3. Gestión de configuración

Ansible, Puppet, Chef, Salt, PowerShell Desired State Configuration y otras herramientas declaran o ejecutan configuraciones. Ansible suele operar sin agente permanente mediante SSH o WinRM, aunque puede usar componentes auxiliares. La idempotencia depende de módulos y diseño del playbook; no toda tarea shell es idempotente.

- name: Asegurar servicio activo
  hosts: servidores
  become: true
  tasks:
    - name: Instalar paquete
      ansible.builtin.package:
        name: chrony
        state: present
    - name: Habilitar e iniciar servicio
      ansible.builtin.service:
        name: chronyd
        enabled: true
        state: started

15.4. Despliegue de sistemas

PXE, servicios de despliegue, imágenes, secuencias de tareas, cloud-init, unattend y aprovisionamiento de nube automatizan instalación. Una imagen gruesa incluye muchas aplicaciones y se vuelve difícil de mantener; una imagen delgada instala componentes después. El enfoque se elige por red, tiempo, variabilidad y operación.

15.5. Monitorización

Las plataformas recogen métricas y estados mediante agentes, protocolos o exportadores. Deben monitorizar servicio y experiencia, no solo host. Un servidor encendido puede ofrecer una aplicación no funcional. Las alertas se diseñan con severidad, deduplicación, dependencia y acción esperada para evitar fatiga.

15.6. Gestión de logs y SIEM

Los colectores centralizan registros y el SIEM correlaciona eventos de seguridad. Es necesario normalizar hora, origen y campos. La retención debe equilibrar investigación, normativa, capacidad y minimización. Los datos de log pueden contener información personal o sensible y deben protegerse.

15.7. Diagnóstico

Las herramientas de traza de llamadas, volcados, perfiles y captura de red permiten bajar de síntoma a causa. Deben utilizarse con cuidado: pueden añadir carga o capturar datos sensibles. Antes de ejecutar se define alcance, duración, almacenamiento y custodia de evidencias.

15.8. Gestión de terminales y UEM

Las soluciones de gestión unificada administran equipos y móviles, distribuyen políticas y aplicaciones, inventarían y evalúan cumplimiento. GPO es específica del ecosistema Windows de dominio; MDM/UEM se adapta a dispositivos móviles y modernos. EDR detecta y responde a amenazas, pero no sustituye MDM; son controles complementarios.

15.9. Control de cambios de automatización

Scripts y plantillas se almacenan en control de versiones, revisan, prueban y publican. Los secretos se referencian desde bóvedas. Las ejecuciones producen logs. En operaciones masivas se limita concurrencia y se usan lotes. Una prueba en modo lectura o simulación reduce el riesgo de aplicar una orden destructiva a miles de sistemas.

16. SISTEMAS OPERATIVOS EN DISPOSITIVOS MÓVILES

16.1. Características

Los sistemas móviles gestionan recursos limitados, sensores, radio, batería, suspensión frecuente, movilidad y aplicaciones distribuidas por tiendas. Priorizan aislamiento, permisos, firma, actualización y experiencia táctil. La organización tiene menos control físico y debe asumir pérdida, redes no confiables y mezcla de uso personal y profesional.

16.2. Arquitectura Android

Android utiliza el kernel Linux para procesos, memoria, controladores y seguridad básica. Encima se sitúan HAL, bibliotecas nativas, Android Runtime, servicios del sistema, framework de API y aplicaciones. La HAL ofrece interfaces estables para funciones de hardware y reduce acoplamiento entre framework e implementación del fabricante. Binder proporciona IPC entre componentes.

Android asigna normalmente un UID a cada aplicación y la ejecuta en su propio proceso, creando una zona de pruebas a nivel de kernel. SELinux añade control obligatorio y política de denegación por defecto. Las aplicaciones solicitan permisos para recursos protegidos. El aislamiento reduce impacto, pero vulnerabilidades, permisos excesivos, ingeniería social o software malicioso siguen siendo posibles.

16.3. Arranque verificado y actualizaciones Android

Verified Boot establece una cadena de confianza desde una raíz protegida hasta particiones verificadas. La separación entre framework y componentes de fabricante facilita evolución, pero el ritmo de actualización depende del fabricante, operador, modelo y programa de soporte. Esta fragmentación es un criterio clave de compra corporativa.

16.4. Arquitectura iOS e iPadOS

Las plataformas de Apple se apoyan en Darwin y el kernel XNU, con capas de servicios y frameworks. Apple integra hardware, sistema, firma de código, arranque seguro y protección de datos. Las aplicaciones están firmadas y aisladas, con permisos y capacidades. El ecosistema más controlado facilita despliegue coherente, pero mantiene dependencia del fabricante y restricciones sobre distribución y personalización.

16.5. Gestión MDM/UEM

MDM permite inscripción, configuración, distribución de certificados, Wi-Fi y VPN, políticas, aplicaciones, inventario, bloqueo y borrado. En dispositivos supervisados se aplican controles adicionales. UEM extiende la gestión a puestos y otros terminales. La herramienta debe integrarse con identidad, cumplimiento y acceso condicional.

16.6. Modelos de propiedad

• COBO: dispositivo corporativo dedicado a uso profesional.
• COPE: corporativo con uso personal permitido bajo reglas.
• BYOD: propiedad del usuario, con separación y privacidad reforzadas.
• Dispositivo compartido o kiosco: uso por varios profesionales o aplicación limitada.

El modelo determina qué puede controlar la organización y qué privacidad conserva el usuario. En BYOD debe evitarse inventariar o borrar datos personales sin base y consentimiento adecuados. El borrado selectivo elimina perfiles y datos gestionados; el borrado completo se reserva a equipos corporativos y escenarios autorizados.

16.7. Aplicaciones y datos

La gestión de aplicaciones distribuye versiones, configuraciones y permisos. Los datos corporativos deben permanecer en aplicaciones y repositorios gestionados cuando sea posible. Las políticas de «abrir en», portapapeles, copia, impresión y almacenamiento en nube reducen fuga. La autenticación debe adaptarse a movilidad sin degradar seguridad.

16.8. Seguridad móvil

Controles relevantes son cifrado, bloqueo, biometría con respaldo, actualización, detección de dispositivo comprometido, prohibición o control de fuentes desconocidas, VPN, certificados, acceso condicional y respuesta remota. Rooting o jailbreak alteran el modelo de confianza. La pérdida física exige bloqueo rápido y revocación de sesiones y certificados, no solo localizar el equipo.

16.9. Ciclo de vida

La compra debe considerar años de soporte y disponibilidad de parches. La inscripción automatizada vincula el dispositivo a la organización desde activación. La baja retira perfiles, aplicaciones, certificados, sesiones y datos; actualiza inventario y asegura borrado conforme al modelo de propiedad. Un móvil no gestionado no debe acceder a información clínica solo porque conoce una contraseña.

16.10. Movilidad sanitaria

El terminal puede utilizarse para consulta, captura, comunicación y autenticación. Los riesgos incluyen visualización por terceros, pérdida, redes inseguras, mezcla de pacientes, notificaciones sensibles y uso con guantes o en zonas de aislamiento. El diseño debe combinar seguridad con flujo clínico: bloqueo breve, autenticación adaptada, mínima información en pantalla y capacidad de uso offline controlado.

17. MAPA CONCEPTUAL Y CLAVES DE EXAMEN

17.1. Distinciones que debes dominar

• Programa / proceso: fichero pasivo frente a instancia en ejecución.
• Proceso listo / bloqueado: espera CPU frente a espera un evento.
• Concurrencia / paralelismo: progreso solapado frente a ejecución simultánea.
• Fallo de página / fallo de segmentación: carga normal posible frente a acceso inválido.
• Instantánea / copia: estado rápido dependiente frente a copia recuperable conforme a política.
• Sistema abierto / código abierto: estándares e interoperabilidad frente a licencia y acceso al código.
• Contenedor / máquina virtual: kernel compartido frente a sistema invitado completo.
• Alta disponibilidad / recuperación ante desastres: continuidad local frente a restauración tras pérdida mayor.
• MDM / EDR: gestión y políticas frente a detección y respuesta de amenazas.

17.2. Perlas oficiales

• UID: identificador interno para propiedad de procesos y ficheros.
• Segmentation fault: acceso a memoria no permitido y actuación del núcleo.
• cron: ejecución programada clásica en Unix/Linux.
• netstat -ano: sockets y PID en Windows.
• MDM: gestión centralizada de móviles.
• Android: puede ser afectado por troyanos; sandbox no significa invulnerabilidad.
• BitLocker: cifrado de volumen en Windows.

17.3. Método de resolución

Ante una pregunta, identifica primero el nivel: hardware, kernel, servicio, aplicación o herramienta de gestión. Después determina si pregunta por mecanismo, política o producto. Rechaza absolutos como «siempre», «nunca» o «impide por completo» cuando la tecnología solo reduce riesgo. En comandos, comprueba qué objeto modifican: chown actúa sobre propiedad de ficheros; kill envía señales; sudo aplica una política de elevación; netstat observa conexiones.