1. INTRODUCCIÓN Y ALCANCE

El sistema operativo constituye la capa fundamental de software que permite convertir los recursos físicos de un sistema informático —procesadores, memoria principal, almacenamiento, interfaces de red y periféricos— en una plataforma utilizable por aplicaciones y usuarios. Su función no consiste únicamente en presentar una interfaz gráfica o un intérprete de órdenes. El sistema operativo crea abstracciones como procesos, hilos, espacios de direcciones, ficheros, sockets, usuarios, grupos, servicios y dispositivos lógicos, y establece las reglas mediante las que todos estos elementos pueden utilizar recursos compartidos de manera eficiente y controlada.

Desde un punto de vista funcional puede afirmarse que el sistema operativo desempeña tres papeles simultáneos. En primer lugar es un gestor de recursos, porque decide cómo se distribuyen CPU, memoria, dispositivos y almacenamiento. En segundo lugar actúa como una máquina extendida, ocultando detalles complejos del hardware tras interfaces relativamente uniformes. Finalmente constituye una frontera de protección, porque separa usuarios, aplicaciones y procesos, controla las operaciones privilegiadas y trata de limitar el impacto de fallos o comportamientos no autorizados.

Esta perspectiva es especialmente importante en organizaciones complejas como el Servicio Andaluz de Salud. Un mismo ecosistema puede contener servidores de aplicaciones y bases de datos, puestos administrativos, terminales clínicos, terminales ligeros, máquinas virtuales, nodos de contenedores, equipos de comunicaciones, tabletas y teléfonos móviles. Aunque las aplicaciones sean distintas, todas dependen de una plataforma de sistema correctamente configurada, actualizada, monitorizada y protegida.

Un fallo aparentemente relacionado con una aplicación puede tener su origen en el sistema operativo. Entre las causas habituales se encuentran una presión excesiva de memoria, un sistema de ficheros sin espacio libre, permisos incorrectos, un certificado caducado, una resolución DNS defectuosa, un reloj desincronizado, un controlador incompatible, un servicio detenido, una actualización pendiente de reinicio o una cola de entrada/salida saturada. La administración de sistemas exige, por tanto, comprender las relaciones entre todos estos subsistemas y no limitarse a reiniciar procesos cuando aparece una incidencia.

El tema incorpora además una dimensión de ciclo de vida. Una plataforma debe seleccionarse, instalarse, configurarse, securizarse, implantarse, administrarse, actualizarse, migrarse y finalmente retirarse. Las decisiones adoptadas en una fase condicionan las siguientes. Por ejemplo, una migración puede resultar inviable si una aplicación depende de un controlador sin soporte en la plataforma destino, de una biblioteca obsoleta, de una arquitectura concreta o de un mecanismo de autenticación no compatible.

También deben evitarse varias equivalencias incorrectas. Sistema abierto no significa necesariamente software de código abierto. Una instantánea no es automáticamente una copia de seguridad. Un contenedor no equivale a una máquina virtual. La alta disponibilidad tampoco sustituye un plan de recuperación ante desastres. Comprender estas diferencias permite resolver gran parte de los distractores habituales en preguntas tipo test.

2. CONCEPTO, OBJETIVOS Y ARQUITECTURA DEL SISTEMA OPERATIVO

2.1. Definición funcional

Un sistema operativo puede definirse como el conjunto coordinado de programas responsables de administrar el hardware, controlar la ejecución de aplicaciones y proporcionar servicios comunes. Las aplicaciones no deberían conocer todos los detalles de cada dispositivo físico. En su lugar utilizan abstracciones proporcionadas por el sistema: un fichero en vez de sectores concretos de un disco, un socket en vez de manipular directamente un adaptador de red o un espacio de memoria virtual en vez de gestionar direcciones físicas.

Esta abstracción simplifica el desarrollo y permite que múltiples aplicaciones compartan recursos de forma controlada. La aplicación solicita una operación mediante bibliotecas o API y, cuando la operación requiere privilegios, termina realizándose una llamada al sistema. Esta produce una transición controlada al núcleo para que se efectúe la operación solicitada después de comprobar parámetros, permisos y estado.

2.2. Objetivos

Entre los objetivos clásicos de un sistema operativo se encuentran la comodidad de uso, el aprovechamiento eficiente del hardware, la protección, la fiabilidad y la capacidad de evolución. A ellos se añaden actualmente la observabilidad, automatización y capacidad de integración con sistemas distribuidos.

• Comodidad: ofrecer abstracciones que simplifican el uso del hardware.
• Eficiencia: utilizar CPU, memoria, almacenamiento y dispositivos con el menor desperdicio posible.
• Equidad: impedir que una única aplicación monopolice injustificadamente recursos compartidos.
• Prioridad: permitir políticas diferenciadas cuando existen cargas con distinta importancia.
• Protección: separar procesos, usuarios y datos.
• Fiabilidad: detectar condiciones anómalas y favorecer recuperación.
• Evolución: incorporar nuevo hardware y funcionalidades manteniendo compatibilidad razonable.
• Observabilidad: proporcionar métricas, registros y estados que permitan diagnosticar el funcionamiento.

2.3. Componentes principales

El kernel es el componente que ejecuta las funciones esenciales en modo privilegiado. A su alrededor se encuentran controladores de dispositivo, bibliotecas, servicios, demonios, shells e interfaces gráficas. Los controladores traducen operaciones genéricas del sistema a las peculiaridades de dispositivos concretos. Los servicios mantienen funcionalidades persistentes como registro, impresión, sincronización horaria, red o administración remota.

2.4. Modo usuario y modo núcleo

Los procesadores modernos ofrecen distintos niveles de privilegio. Las aplicaciones ordinarias se ejecutan en un nivel restringido, denominado genéricamente modo usuario. No pueden modificar libremente las tablas de memoria, acceder directamente a cualquier dispositivo o ejecutar determinadas instrucciones críticas. El núcleo utiliza el nivel privilegiado.

Las transiciones se producen de forma controlada mediante llamadas al sistema, interrupciones y excepciones. Una excepción puede originarse, por ejemplo, cuando una aplicación intenta dividir entre cero, utiliza una instrucción no permitida o realiza un acceso inválido a memoria. El sistema operativo recibe el control y decide cómo tratar la situación.

2.5. Núcleo monolítico, micronúcleo e híbrido

En una arquitectura monolítica una parte importante de los servicios esenciales se ejecuta en espacio privilegiado. Linux suele describirse como un núcleo monolítico modular, porque admite módulos cargables aunque estos se ejecutan con privilegios del kernel. La ventaja puede ser un acceso eficiente entre subsistemas; el inconveniente es que un error grave dentro del espacio privilegiado puede comprometer todo el sistema.

Un micronúcleo conserva en modo privilegiado un conjunto reducido de mecanismos fundamentales y desplaza otros servicios a procesos separados. Esto puede mejorar modularidad y aislamiento, aunque incrementa la comunicación entre componentes. Los denominados núcleos híbridos combinan características de diferentes enfoques.

Estas categorías son útiles para comprender arquitectura, pero no deben utilizarse para deducir automáticamente seguridad o rendimiento. La calidad final depende de la implementación, modelo de controladores, interfaces, políticas, mecanismos de aislamiento y mantenimiento del producto.

2.6. API, ABI y portabilidad

Una API especifica cómo un programa utiliza funciones y servicios a nivel de código. Una ABI añade detalles binarios: convenciones de llamada, representación de tipos, formato de ejecutables, registros y otros aspectos necesarios para ejecutar código compilado. Dos sistemas pueden ofrecer API conceptualmente parecidas y no ser compatibles a nivel binario.

La portabilidad puede conseguirse a distintos niveles. Un estándar como POSIX favorece portabilidad del código fuente. Una ABI estable permite compatibilidad binaria dentro de determinadas condiciones. Las máquinas virtuales de lenguaje y otros runtimes proporcionan otra capa de abstracción. La elección influye directamente en planes de migración.

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

3.1. Programa y proceso

Un programa es una representación pasiva de instrucciones y datos almacenada en algún soporte. Un proceso es una instancia de ese programa en ejecución. El sistema operativo mantiene información necesaria para gestionarlo: identificador, estado, prioridad, contexto de CPU, espacio de memoria, credenciales, ficheros abiertos, estadísticas, señales pendientes y relaciones con otros procesos.

El proceso constituye una de las abstracciones fundamentales del sistema. Permite que diferentes aplicaciones parezcan disponer de su propia CPU y memoria aunque físicamente compartan los mismos recursos. El aislamiento evita que una aplicación pueda modificar libremente la memoria de otra.

3.2. Estados

Los modelos académicos suelen representar los procesos mediante estados como nuevo, preparado, en ejecución, bloqueado y terminado. La terminología exacta cambia entre sistemas, pero la distinción conceptual es importante.

• Preparado: puede ejecutar y espera que se le asigne CPU.
• En ejecución: está utilizando una unidad de procesamiento.
• Bloqueado: espera que ocurra un evento y todavía no puede continuar.
• Terminado: ha finalizado su ejecución, aunque el sistema puede conservar temporalmente determinada información administrativa.

Un proceso que espera completar una lectura de disco no debe competir continuamente por CPU. Se bloquea y el procesador puede dedicarse a otro trabajo. Cuando llega la interrupción que indica que la operación ha terminado, puede regresar al conjunto de entidades preparadas.

3.3. Hilos

Un hilo es una unidad de ejecución dentro de un proceso. Los hilos de un mismo proceso comparten normalmente código, datos, espacio de direcciones y descriptores de determinados recursos, pero mantienen contador de programa, registros y pila propios.

El uso de hilos facilita concurrencia dentro de una aplicación. Un servidor puede atender simultáneamente diferentes peticiones o una interfaz gráfica puede mantener respuesta mientras otra tarea realiza entrada/salida. Sin embargo, compartir memoria introduce problemas de sincronización. Dos hilos que modifican simultáneamente los mismos datos pueden generar una condición de carrera.

3.4. Concurrencia y paralelismo

Concurrencia significa que varias actividades progresan durante un intervalo temporal. Paralelismo implica ejecución simultánea real. Un equipo con una única CPU puede mantener concurrencia alternando rápidamente entre tareas. Un procesador multinúcleo puede ejecutar varios hilos simultáneamente y proporcionar paralelismo físico.

El paralelismo no garantiza que una aplicación sea más rápida. El trabajo debe poder dividirse, y aparecen costes de sincronización, acceso a memoria, contención y coordinación. Una sección crítica excesivamente grande puede anular gran parte del beneficio de disponer de múltiples núcleos.

3.5. Planificación de CPU

El planificador selecciona qué proceso o hilo preparado utilizará la CPU. Los objetivos pueden incluir capacidad de respuesta, equidad, rendimiento total, cumplimiento de prioridades y, en sistemas de tiempo real, respeto de plazos.

Los algoritmos clásicos utilizados con finalidad didáctica incluyen FCFS, trabajo más corto, planificación por prioridad y round robin. FCFS atiende aproximadamente según orden de llegada y puede perjudicar trabajos cortos situados detrás de uno muy largo. SJF favorece trabajos breves cuando puede conocerse o estimarse su duración. La planificación por prioridades atiende valores asignados, pero necesita mecanismos para evitar inanición. Round robin asigna un cuanto temporal y es característico del razonamiento sobre sistemas interactivos de tiempo compartido.

Los sistemas operativos actuales implementan políticas considerablemente más complejas. Pueden utilizar distintas clases de planificación, prioridades dinámicas, afinidad con CPU, topología NUMA, consumo energético y características del hardware. Para la oposición debe dominarse el principio, no asumir que un sistema real utiliza de manera literal un único algoritmo académico.

3.6. Cambio de contexto

Cuando el sistema cambia de una tarea a otra debe guardar parte del estado de la tarea saliente y restaurar el de la entrante. Esta operación se denomina cambio de contexto. Es necesaria para la multitarea, pero consume tiempo. Una carga con un número exagerado de hilos puede invertir una cantidad apreciable de recursos en planificación y cambios de contexto.

3.7. Sincronización

Cuando varias entidades acceden a datos compartidos deben coordinarse. Mutex, semáforos, monitores, variables de condición y operaciones atómicas son ejemplos de mecanismos de sincronización. El objetivo es mantener las invariantes de los datos sin bloquear innecesariamente el paralelismo.

Una condición de carrera aparece cuando el resultado depende de un orden de ejecución no controlado. El problema puede ser extremadamente difícil de reproducir porque desaparece al añadir trazas o depuración. Por ello el diseño correcto de la sincronización es preferible a intentar detectar errores posteriormente.

3.8. Interbloqueo

Un deadlock o interbloqueo aparece cuando un conjunto de procesos queda esperando indefinidamente recursos que están retenidos por miembros del propio conjunto. El modelo clásico de Coffman identifica condiciones como exclusión mutua, retención y espera, ausencia de expropiación y espera circular.

Las estrategias de tratamiento incluyen prevención, evitación, detección y recuperación. El algoritmo del banquero es un ejemplo didáctico de evitación mediante análisis de estados seguros. En la práctica muchos sistemas y aplicaciones utilizan mecanismos diferentes según la naturaleza del recurso.

3.9. Comunicación entre procesos

Los procesos necesitan intercambiar información. Los sistemas operativos proporcionan mecanismos IPC como tuberías, colas de mensajes, señales, memoria compartida, semáforos y sockets. La memoria compartida puede ofrecer gran rendimiento porque evita copias innecesarias, pero requiere sincronización explícita. Los sockets permiten además extender la comunicación a diferentes máquinas.

En sistemas distribuidos, gran parte del software utiliza protocolos y middleware situados por encima de estos mecanismos básicos. Sin embargo, el sistema operativo sigue proporcionando sockets, buffers, temporizadores y planificación sobre los que descansa la comunicación.

4. GESTIÓN DE MEMORIA

4.1. Objetivos

La gestión de memoria debe permitir que múltiples procesos utilicen de forma segura un recurso físico limitado. El sistema debe conocer qué regiones están ocupadas, asignar y liberar espacio, proteger procesos entre sí, compartir regiones de manera controlada y proporcionar una visión lógica adecuada a cada aplicación.

La memoria constituye además una frontera de seguridad. Una aplicación ordinaria no debe poder leer o modificar cualquier dirección física del equipo. El hardware de gestión de memoria y el kernel cooperan para traducir direcciones y comprobar permisos.

4.2. Espacio de direcciones

Cada proceso dispone conceptualmente de su propio espacio de direcciones virtuales. Las direcciones utilizadas por el programa se traducen a posiciones físicas mediante estructuras administradas por el sistema operativo y mecanismos de hardware. Esto permite que dos procesos utilicen aparentemente la misma dirección virtual sin referirse a la misma memoria física.

El aislamiento no impide toda compartición. Bibliotecas, memoria compartida o regiones mapeadas pueden asociar determinadas páginas a varios procesos, pero de forma explícita y con permisos definidos.

4.3. Paginación

La paginación divide el espacio virtual y la memoria física en unidades de tamaño determinado denominadas páginas y marcos. Las tablas de páginas mantienen las asociaciones. Como recorrer estas estructuras en cada referencia sería costoso, los procesadores utilizan mecanismos de caché de traducciones, habitualmente denominados TLB.

La paginación evita la necesidad de que un proceso ocupe un único bloque físico contiguo. También facilita protección y carga bajo demanda. A cambio aparecen costes de traducción, tablas de páginas, fallos de página y posibles problemas de localidad.

4.4. Memoria virtual y demanda

La memoria virtual no debe definirse simplemente como «utilizar disco cuando se acaba la RAM». Su función principal es proporcionar una abstracción de memoria protegida y flexible. La paginación bajo demanda permite cargar determinadas páginas cuando realmente se utilizan.

Cuando una referencia apunta a una página no presente, el procesador genera una excepción. El kernel determina si la referencia es válida. Si lo es y los datos deben recuperarse de almacenamiento, se inicia la operación correspondiente y el proceso puede quedar bloqueado. Cuando termina, la instrucción puede reanudarse. Si el acceso era ilegítimo, el sistema lo trata como una violación.

4.5. Reemplazo y presión de memoria

Cuando es necesario liberar memoria física pueden seleccionarse páginas candidatas para ser sustituidas. Algoritmos académicos como FIFO o LRU ayudan a estudiar el problema, aunque los sistemas reales utilizan aproximaciones más complejas.

La métrica relevante no es únicamente el porcentaje de RAM ocupada. Parte de la memoria puede emplearse como caché y liberarse cuando otra aplicación la necesita. Para diagnosticar presión deben observarse conjunto residente, memoria disponible, fallos de página, actividad de intercambio, latencia y comportamiento de las aplicaciones.

Cuando la frecuencia de fallos de página es excesiva y el sistema dedica una parte importante del tiempo a mover páginas en vez de ejecutar trabajo útil aparece el fenómeno conocido como thrashing. Añadir memoria puede resolverlo si existe presión genuina, pero no corrige una fuga ilimitada de memoria.

4.6. Segmentación

La segmentación representa la memoria mediante regiones lógicas de tamaño variable. Históricamente se utilizó para reflejar componentes como código, datos o pila. Los sistemas modernos pueden combinar diferentes mecanismos y las arquitecturas actuales se apoyan ampliamente en paginación para implementar protección y memoria virtual.

Para la oposición conviene diferenciar la idea conceptual: las páginas tienen normalmente tamaño fijo dentro de una determinada configuración, mientras que los segmentos representan unidades lógicas de tamaño variable.

4.7. Protección

Las páginas pueden disponer de atributos de lectura, escritura y ejecución. Esto permite, por ejemplo, impedir que una región de datos se ejecute o que una página de código de solo lectura se modifique. La separación entre espacios de usuario y núcleo añade otra frontera.

Los sistemas modernos combinan estas protecciones con técnicas como aleatorización de espacios de direcciones y mecanismos de protección frente a ejecución de datos. Ningún mecanismo elimina todas las vulnerabilidades, pero aumentan las barreras frente a explotación de errores.

4.8. Memoria en sistemas virtualizados y contenedores

La virtualización introduce una capa adicional de asignación. El sistema invitado administra una memoria que considera física, mientras el hipervisor mantiene la relación con la memoria real. Pueden existir técnicas de sobreasignación, páginas grandes y optimizaciones específicas.

En contenedores se comparte el kernel, pero pueden establecerse límites y contabilidad de memoria mediante mecanismos de control de recursos. Si una carga supera límites configurados, el sistema puede tener que recuperar memoria o terminar procesos conforme a sus políticas.

5. ENTRADA/SALIDA, DISPOSITIVOS Y SISTEMAS DE FICHEROS

5.1. Subsistema de entrada/salida

Los dispositivos presentan características muy diferentes: discos, interfaces de red, teclado, pantalla, USB o dispositivos especializados. El sistema operativo oculta parte de esta heterogeneidad mediante controladores e interfaces comunes. Una aplicación normalmente no necesita programar directamente los registros hardware de un dispositivo.

Las operaciones de entrada/salida suelen ser mucho más lentas que las operaciones internas de la CPU. Por ello el sistema utiliza interrupciones, DMA, buffers, colas y cachés para reducir esperas y aprovechar mejor el procesador.

5.2. Interrupciones

Una interrupción permite que el hardware solicite atención del procesador. En vez de esperar activamente a que un dispositivo termine, el sistema puede ejecutar otro trabajo y recibir una interrupción cuando haya datos disponibles. El tratamiento debe ser eficiente, porque un número excesivo de interrupciones puede consumir una parte importante de la capacidad.

5.3. Controladores

El driver implementa la lógica necesaria para controlar un dispositivo y presentarlo mediante interfaces del sistema. Los controladores que ejecutan en modo núcleo deben tratarse con especial cuidado: un defecto puede afectar a toda la estabilidad de la plataforma. Por esta razón las matrices de compatibilidad de hardware son críticas durante una migración.

Un periférico puede funcionar correctamente con una versión del sistema operativo y dejar de hacerlo tras una actualización si desaparece el soporte del controlador. En puestos sanitarios deben incluirse en las pruebas lectores, impresoras, escáneres y cualquier equipamiento especializado integrado con aplicaciones.

5.4. Sistemas de ficheros

El sistema de ficheros proporciona nombres, directorios, metadatos, permisos y mecanismos de organización sobre dispositivos de almacenamiento. También debe mantener consistencia y gestionar asignación de bloques.

Entre los sistemas de ficheros conocidos se encuentran familias FAT, NTFS, ext y XFS, entre otras. Su elección depende de plataforma, tamaño, fiabilidad, soporte, permisos, recuperación, rendimiento y compatibilidad. No existe un sistema universalmente mejor.

5.5. Metadatos y permisos

Un fichero tiene contenido y metadatos. Entre estos últimos pueden encontrarse propietario, grupo, permisos, marcas temporales, tamaño y otros atributos. La interpretación exacta depende del sistema de ficheros y del sistema operativo.

Los directorios también tienen permisos. En Unix/Linux, por ejemplo, lectura, escritura y ejecución sobre un directorio no significan exactamente lo mismo que sobre un fichero. La ejecución permite atravesar el directorio, mientras que la lectura se relaciona con enumerar sus entradas.

5.6. Caché y escritura

El sistema operativo utiliza memoria como caché de datos y metadatos para reducir operaciones físicas. Una escritura realizada por una aplicación puede quedar temporalmente en memoria antes de alcanzar el soporte estable. Esto mejora rendimiento, pero obliga a diseñar mecanismos de sincronización y recuperación.

Una aplicación que necesita garantías de persistencia debe utilizar las interfaces adecuadas y comprender las garantías ofrecidas por sistema de ficheros, dispositivo y controlador. El hecho de que una función de escritura haya devuelto control no implica necesariamente que todos los niveles físicos hayan persistido ya el dato.

5.7. Journaling

El journaling registra determinada información sobre las modificaciones para ayudar a restaurar consistencia después de una interrupción. Según el sistema puede registrar metadatos o distintos grados de información. Reduce los tiempos y riesgos de recuperación, pero no sustituye una copia de seguridad.

5.8. Instantáneas

Una instantánea representa el estado de un volumen o conjunto de datos en un momento. Puede crearse con rapidez y resultar muy útil para recuperación inmediata o pruebas. Sin embargo, si comparte el mismo dominio de fallo que los datos originales, la pérdida del almacenamiento puede destruir original e instantánea.

Una política de backup debe mantener copias conforme a objetivos de recuperación, retención, aislamiento y seguridad. Además debe probarse la restauración. Una copia que nunca se ha restaurado satisfactoriamente aporta una confianza limitada.

5.9. Rendimiento de almacenamiento

Para diagnosticar almacenamiento deben diferenciarse IOPS, caudal, latencia y profundidad de cola. Una aplicación con numerosas operaciones pequeñas y aleatorias tiene un comportamiento distinto de una transferencia secuencial de grandes ficheros. La observación debe abarcar aplicación, sistema operativo, caché, sistema de ficheros y dispositivo.

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

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

La identificación establece qué identidad afirma utilizar un sujeto. La autenticación verifica esa afirmación. La autorización decide qué operaciones puede realizar la identidad autenticada. Estas tres fases no deben confundirse.

Los sistemas operativos administran usuarios, grupos, tokens, privilegios y listas de control. En un entorno corporativo las identidades pueden proceder de servicios centralizados y las políticas se distribuyen a numerosos sistemas.

6.2. Principio de mínimo privilegio

Usuarios, servicios y aplicaciones deben disponer únicamente de los permisos necesarios para su función. Ejecutar aplicaciones sistemáticamente como administrador o root aumenta el impacto de errores y compromisos. Las cuentas administrativas deben diferenciarse de las cuentas ordinarias y utilizarse únicamente cuando sea necesario.

Las cuentas de servicio requieren un ciclo de vida específico: propietario, finalidad, permisos mínimos, mecanismos de protección de credenciales, revisión y retirada cuando deje de existir el servicio.

6.3. Control de acceso

Los permisos tradicionales pueden complementarse mediante ACL, capacidades y modelos de control obligatorio. SELinux es un ejemplo de mecanismo MAC disponible en Linux. Una operación puede tener que superar simultáneamente permisos discrecionales y políticas obligatorias.

Desactivar un mecanismo de seguridad para conseguir que una aplicación funcione puede ser útil únicamente como prueba diagnóstica controlada. No constituye una solución permanente. Debe identificarse la regla concreta y aplicar una excepción mínima.

6.4. Cifrado

El cifrado de almacenamiento protege principalmente datos en reposo frente a determinados escenarios, como pérdida o extracción de un soporte. BitLocker en Windows y mecanismos basados en LUKS en Linux son ejemplos conocidos de protección de volúmenes.

El cifrado no sustituye control de acceso. Cuando un volumen está desbloqueado, un usuario o proceso autorizado puede leer información en claro. Del mismo modo, malware ejecutándose con credenciales suficientes podría acceder a datos ya descifrados.

6.5. Auditoría y logs

Los registros permiten reconstruir actividad, diagnosticar fallos y detectar comportamientos de seguridad. Deben incluir contexto suficiente: fecha, origen, identidad, evento, resultado y correlación cuando proceda.

La sincronización horaria es imprescindible para correlacionar eventos entre sistemas. Si dos servidores mantienen relojes muy diferentes, una investigación puede interpretar incorrectamente la secuencia de acciones.

Los logs también pueden contener información sensible. La centralización debe aplicar control de acceso, integridad, retención apropiada y minimización. Registrar absolutamente todos los datos sin diseño previo puede generar costes y riesgos sin mejorar la capacidad de análisis.

6.6. Observabilidad

La observabilidad combina señales como métricas, registros y trazas. En un sistema operativo se observan utilización y saturación de CPU, memoria disponible, paginación, latencia de E/S, espacio en ficheros, procesos, servicios, conexiones, errores y reinicios.

Una única métrica rara vez basta. Una CPU al 100 % puede significar uso eficiente o saturación. Debe correlacionarse con cola de trabajo, latencia y objetivo del servicio. De forma similar, utilizar casi toda la RAM puede ser completamente normal si una parte importante corresponde a caché recuperable.

6.7. Hardening

El endurecimiento reduce la superficie de ataque. Comprende eliminar componentes innecesarios, limitar servicios y puertos, reforzar administración remota, aplicar actualizaciones, proteger credenciales, configurar auditoría y utilizar políticas de mínimo privilegio.

La configuración segura debe expresarse preferiblemente como una línea base versionada. Esto permite saber qué estado se considera autorizado y detectar deriva. Las excepciones deben documentarse, tener justificación y revisarse periódicamente.

6.8. Esquema Nacional de Seguridad

En sistemas del sector público español, la operación del sistema operativo debe encajar en el marco del Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. El ENS afecta a la gestión global de la seguridad, no exclusivamente a una aplicación concreta.

Medidas como control de acceso, configuración segura, actualización, registro de actividad, protección de información y continuidad tienen traducción práctica directa en la administración de sistemas operativos. El administrador debe aplicar las políticas definidas para el sistema y conservar evidencias de cumplimiento.

7. EVOLUCIÓN Y TENDENCIAS DE LOS SISTEMAS OPERATIVOS

7.1. Procesamiento por lotes

Los primeros sistemas ejecutaban trabajos preparados con antelación. El operador organizaba programas y datos y la máquina procesaba lotes con poca interacción directa. El objetivo era mejorar la utilización de hardware extremadamente costoso y reducir tiempos muertos entre trabajos.

Los monitores residentes y sistemas de control de trabajos fueron precursores de funciones posteriores del sistema operativo. La evolución se dirigió progresivamente hacia una administración más automática de CPU, dispositivos y memoria.

7.2. Multiprogramación

La multiprogramación permitió mantener varios trabajos disponibles, de forma que la CPU pudiera ejecutar otro cuando uno quedaba esperando entrada/salida. Esto exigió protección de memoria, interrupciones y planificación.

Posteriormente el tiempo compartido extendió el modelo para ofrecer interacción a diferentes usuarios. El reparto rápido del procesador generaba la percepción de disponer de una máquina propia. Los requisitos de seguridad y aislamiento aumentaron de manera considerable.

7.3. Unix y portabilidad

Unix constituyó una referencia histórica especialmente relevante por su carácter multiusuario, multitarea, filosofía de herramientas componibles y amplia influencia posterior. La reimplementación de buena parte del sistema en C facilitó su adaptación a diferentes arquitecturas.

La proliferación de variantes generó la necesidad de normalizar interfaces. De este contexto surgieron esfuerzos de estandarización que culminaron, entre otros, en especificaciones POSIX.

7.4. Ordenador personal

La expansión de los ordenadores personales trasladó parte del interés hacia interfaces gráficas, facilidad de uso y compatibilidad con periféricos. Los primeros sistemas personales ofrecían mecanismos de protección y multitarea más limitados que los grandes sistemas multiusuario.

Las arquitecturas posteriores incorporaron progresivamente separación de procesos, memoria virtual, seguridad multiusuario, red integrada y administración corporativa. Windows NT y las plataformas modernas derivadas de Darwin son ejemplos de esta evolución.

7.5. Linux

Linux apareció como kernel compatible con principios Unix y se combinó con numerosas herramientas del proyecto GNU y otros componentes para formar distribuciones completas. Una distribución añade instalador, gestor de paquetes, repositorios, bibliotecas, servicios, herramientas de administración y políticas de mantenimiento.

7.6. Virtualización

La virtualización desacopló la máquina lógica del hardware físico. Un hipervisor puede presentar CPU, memoria, almacenamiento y red virtuales a diferentes sistemas invitados. Esto permite consolidación, aprovisionamiento rápido, aislamiento y mayor flexibilidad operativa.

No obstante, una VM sigue necesitando administración del sistema invitado: usuarios, parches, agentes, servicios, logs y copias. Crear una máquina virtual es fácil; mantener correctamente cientos o miles de ellas exige automatización e inventario.

7.7. Cloud computing

La nube ha reforzado el tratamiento del sistema operativo como un componente automatizable. En IaaS, el proveedor gestiona infraestructura física y virtualización, pero el consumidor continúa siendo responsable de numerosos aspectos del sistema invitado.

Las imágenes, plantillas e infraestructura como código permiten crear sistemas repetibles. La tendencia es evitar configuraciones manuales únicas y reemplazarlas por estados declarados, versionados y verificables.

7.8. Contenedores

Los contenedores aíslan procesos utilizando mecanismos del kernel y comparten el núcleo del host. La imagen incluye principalmente espacio de usuario, aplicación y dependencias. Esto reduce peso frente a una máquina virtual completa, pero el modelo de aislamiento es diferente.

Esto explica por qué no puede asumirse que una imagen construida para ejecutar procesos Linux funcione directamente sobre un kernel Windows sin una capa de compatibilidad o virtualización apropiada. El espacio de usuario puede variar, pero las llamadas al sistema terminan siendo atendidas por el kernel disponible.

7.9. Sistemas inmutables

Una tendencia moderna consiste en reducir cambios interactivos realizados directamente sobre servidores. Se construyen imágenes conocidas, se validan y se despliegan como unidades. Cuando es necesario actualizar, se sustituye el estado completo en vez de acumular modificaciones manuales.

Este enfoque disminuye la deriva de configuración y facilita reproducibilidad. Exige, sin embargo, separar adecuadamente datos persistentes, configuración, secretos y estado de la aplicación.

7.10. Edge, IoT y tiempo real

Los sistemas de borde ejecutan procesamiento cerca de la fuente de datos, reduciendo latencia y dependencia de conectividad. En IoT adquieren especial importancia consumo, actualizaciones remotas, arranque seguro y ciclo de soporte.

Los sistemas operativos de tiempo real priorizan previsibilidad y cumplimiento de plazos. No deben definirse simplemente como sistemas «muy rápidos»: su característica fundamental es ofrecer comportamiento temporal suficientemente determinista para el escenario de uso.

7.11. Seguridad integrada

TPM, arranque seguro, firma de código, cifrado y mecanismos de aislamiento por hardware forman parte cada vez más del diseño ordinario de plataformas. La seguridad deja de ser un producto añadido al final y se integra desde la secuencia de arranque hasta la identidad de usuario.

7.12. Automatización e inteligencia artificial

La administración utiliza cada vez más automatización, análisis de telemetría y asistencia basada en IA. Estas tecnologías pueden clasificar eventos, sugerir comandos o localizar anomalías, pero no eliminan la necesidad de autorización, revisión, control de cambios y reversión.

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

8.1. Sistema abierto

Un sistema abierto utiliza especificaciones e interfaces que favorecen interoperabilidad y portabilidad. La apertura puede referirse a protocolos, API, formatos, mecanismos de autenticación o interfaces de administración. No obliga a que todo el código fuente esté disponible.

La importancia de los estándares reside en disminuir dependencias innecesarias. Si varias implementaciones respetan una interfaz común, las aplicaciones disponen de mayor posibilidad de adaptación. No obstante, cada producto puede incorporar extensiones particulares que reduzcan esa portabilidad.

8.2. POSIX

POSIX, Portable Operating System Interface, normaliza interfaces del sistema operativo, entorno de shell y utilidades con el objetivo de facilitar la portabilidad de aplicaciones a nivel de código fuente. IEEE Std 1003.1-2024 y The Open Group Base Specifications, Issue 8, constituyen referencias de POSIX.1-2024.

La conformidad con POSIX no significa que dos sistemas sean idénticos. Pueden existir diferentes kernels, herramientas de administración, sistemas de paquetes, formatos binarios e interfaces gráficas y aun así compartir un subconjunto importante de interfaces normalizadas.

8.3. Código abierto

El software de código abierto se distribuye mediante licencias que proporcionan determinados derechos de acceso, modificación y redistribución del código. Existen licencias con obligaciones distintas. Algunas utilizan mecanismos copyleft; otras son más permisivas.

Código abierto tampoco significa necesariamente gratuito. Una empresa puede vender soporte, integración, certificación o suscripciones de una plataforma cuyo código esté disponible. De forma inversa, que un producto pueda utilizarse sin pagar una licencia determinada no lo convierte automáticamente en open source.

8.4. Sistemas propietarios

En un sistema propietario el proveedor conserva un control mayor sobre código, licencia, evolución y distribución. Entre sus posibles ventajas se encuentran un soporte unificado, certificaciones, herramientas integradas y compatibilidad estrecha dentro del propio ecosistema.

Entre sus riesgos pueden encontrarse mayor dependencia de decisiones comerciales, cambios de licenciamiento o finalización del soporte. No obstante, tampoco debe asumirse que una solución abierta carece de dependencias: una distribución concreta, un integrador o determinadas competencias profesionales pueden generar dependencia operativa.

8.5. Comparación

8.6. Coste total de propiedad

El análisis económico debe utilizar el TCO y no únicamente el precio de la licencia. Deben contabilizarse implantación, migración, hardware, formación, personal, soporte, monitorización, seguridad, indisponibilidad, actualización y retirada.

Una plataforma sin coste de licencia puede exigir más integración o conocimientos especializados. Una solución propietaria puede resultar competitiva si reduce costes de operación. La decisión debe basarse en requisitos y evidencias.

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

9.1. Administración como ciclo continuo

Administrar un sistema operativo significa mantenerlo en un estado conocido durante todo su ciclo de vida. La actividad comienza antes de instalar, definiendo finalidad, propietario, criticidad, requisitos y dependencias. Termina cuando se retiran datos, credenciales, certificados, registros y activos de inventario.

La administración madura no depende de conocimientos tácitos de una única persona. Debe apoyarse en inventario, procedimientos, automatización, monitorización y evidencias.

9.2. Inventario

El inventario debe identificar equipo, arquitectura, sistema operativo, versión, edición, función, ubicación, propietario, red, aplicaciones y estado de soporte. En entornos virtuales también deben conocerse host, clúster, almacenamiento y relaciones con otros componentes.

Una CMDB puede ayudar a representar estas relaciones, pero únicamente aporta valor si los datos se actualizan y se utilizan durante cambios e incidencias. Una base desactualizada puede incluso aumentar riesgo al generar falsa confianza.

9.3. Gestión de configuración

La configuración autorizada debe definirse mediante una línea base. Incluye servicios, puertos, parámetros, software, cuentas, políticas y mecanismos de seguridad. Posteriormente se compara el estado real para detectar configuration drift.

El uso de herramientas declarativas facilita mantener numerosos sistemas coherentes. Sin embargo, automatizar una configuración incorrecta propaga el error más rápidamente. Las plantillas deben someterse a revisión y pruebas.

9.4. Identidades

Las cuentas siguen un ciclo de alta, modificación, revisión y baja. Deben evitarse cuentas compartidas que impidan atribuir acciones. Las cuentas administrativas necesitan controles reforzados y las cuentas de servicio requieren responsables y permisos mínimos.

9.5. Gestión de software y parches

La administración debe controlar origen, versión, firma y dependencias del software instalado. Las actualizaciones se prueban antes de llegar a sistemas críticos. Una práctica común es utilizar anillos o grupos: laboratorio, piloto, producción no crítica y producción crítica.

También deben considerarse reinicios. Una actualización instalada pero pendiente de reinicio puede no haber activado todavía todos los componentes corregidos.

9.6. Capacidad

La gestión de capacidad observa tendencias de CPU, memoria, almacenamiento y red respecto a la demanda. Las medias agregadas no bastan para cargas con picos. Deben analizarse percentiles, máximos, crecimiento y estacionalidad.

El objetivo tampoco consiste en mantener todos los recursos permanentemente infrautilizados. Un sistema excesivamente sobredimensionado incrementa costes. Se busca margen suficiente para cumplir niveles de servicio y soportar fallos razonables.

9.7. Disponibilidad y continuidad

Alta disponibilidad y recuperación ante desastres responden a escenarios diferentes. La primera trata de reducir interrupciones mediante redundancia y conmutación. La segunda aborda restauración después de una pérdida grave.

El sistema operativo participa en ambos escenarios mediante arranque, clústeres, servicios, almacenamiento y automatización, pero la continuidad debe abarcar también aplicaciones, datos, identidad, comunicaciones, procedimientos y personas.

9.8. Copia y recuperación

La política de backup define qué se copia, frecuencia, retención, cifrado, destino y pruebas. El RPO indica la pérdida máxima de datos tolerable expresada como objetivo temporal; el RTO representa el tiempo objetivo para recuperar el servicio.

No basta con ejecutar trabajos de copia sin errores. Deben realizarse restauraciones periódicas. También deben protegerse configuraciones, certificados y claves necesarias para recuperar la plataforma.

9.9. Incidencias

Ante una incidencia debe capturarse el estado antes de aplicar acciones destructivas: hora, cambios recientes, procesos, memoria, conexiones, espacio, logs y eventos. Reiniciar puede restaurar el servicio, pero puede borrar evidencia necesaria para identificar la causa.

La gestión de problemas busca ir más allá de la recuperación inmediata y localizar la causa raíz o los factores que permitieron la recurrencia.

9.10. Cambios

Un cambio significativo debe disponer de objetivo, alcance, riesgo, procedimiento, pruebas, ventana y plan de reversión. La documentación final debe reflejar el estado as-built y no únicamente el diseño teórico previo a la implantación.

10. ADMINISTRACIÓN DE SISTEMAS UNIX Y LINUX

10.1. Usuarios e identificadores

Linux utiliza identificadores numéricos UID y GID. Los nombres son representaciones legibles asociadas a esos identificadores. La propiedad de los objetos se registra mediante identificadores, por lo que reutilizar accidentalmente un UID puede hacer que una cuenta nueva aparezca como propietaria de ficheros antiguos.

El UID 0 representa tradicionalmente la identidad con privilegios de superusuario. El objetivo de una administración segura es evitar ejecutar innecesariamente tareas ordinarias con ese nivel de privilegio.

id usuario
getent passwd usuario
getent group grupo

10.2. Permisos

Los permisos clásicos se expresan para propietario, grupo y otros. Las operaciones fundamentales son lectura, escritura y ejecución. En notación octal, lectura vale 4, escritura 2 y ejecución 1. La suma representa los permisos de cada categoría.

Así, 644 corresponde a lectura y escritura para el propietario y solo lectura para grupo y otros. El modo 750 ofrece todos los permisos al propietario, lectura y ejecución al grupo y ninguno a otros.

ls -l /ruta
chmod 640 fichero
chown usuario:grupo fichero

10.3. ACL

Las ACL permiten representar permisos adicionales más allá de propietario, grupo y otros. Son útiles cuando varios usuarios o grupos necesitan permisos específicos sin alterar la estructura principal de propiedad.

getfacl /ruta/fichero
setfacl -m u:usuario:rw /ruta/fichero

10.4. Elevación de privilegios

sudo permite ejecutar operaciones con otra identidad según una política. Su ventaja es que evita compartir indiscriminadamente la contraseña de root y permite atribuir la operación al usuario que solicitó la elevación.

La política debe aplicar mínimo privilegio. Conceder acceso indiscriminado a cualquier comando puede ser funcionalmente equivalente a entregar acceso total de administración.

10.5. Procesos

ps ofrece una instantánea de procesos. top muestra una vista dinámica. pgrep localiza procesos y kill envía señales. Una señal no es necesariamente una «orden de matar»: depende de qué señal se envíe.

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

SIGTERM solicita una terminación ordenada que el proceso puede gestionar. SIGKILL no puede ser capturada por el proceso y debe reservarse para situaciones en las que no es posible obtener una terminación normal.

10.6. Servicios y systemd

Muchas distribuciones actuales utilizan systemd como gestor de servicios y arranque. Las unidades representan servicios, sockets, montajes y otros recursos. systemctl permite consultar y modificar su estado.

systemctl status servicio
systemctl list-dependencies servicio
systemctl enable --now servicio

start o iniciar modifica el estado actual. Habilitar un servicio afecta a su activación durante posteriores arranques conforme a las dependencias configuradas. Ambos conceptos no deben confundirse.

10.7. Journal

En sistemas con journal de systemd, journalctl permite consultar registros y aplicar filtros por unidad, tiempo, prioridad o arranque.

journalctl -u servicio
journalctl -u servicio --since "-1 hour"
journalctl -p warning..alert -b

Antes de reiniciar repetidamente un servicio conviene revisar código de salida, dependencias y eventos relacionados. Reiniciar puede eliminar el síntoma temporalmente sin resolver la causa.

10.8. Tareas programadas

cron constituye el mecanismo clásico de ejecución periódica basado en calendarios. Las tareas se ejecutan con un entorno que puede ser diferente de una sesión interactiva; por ello deben controlarse rutas, variables, usuario y directorio de trabajo.

Los temporizadores de systemd proporcionan otra forma de programación y se integran con unidades, dependencias y journal. La elección depende de plataforma y requisitos.

10.9. Paquetes

Las distribuciones utilizan gestores de paquetes y repositorios. La administración corporativa debe controlar qué repositorios están autorizados, validar firmas y evitar instalaciones manuales no inventariadas.

apt update
apt list --upgradable

dnf check-update
dnf history

Los comandos pertenecen a familias diferentes de distribuciones. No debe suponerse que un gestor está disponible en cualquier Linux.

10.10. Red

La administración de red comprende interfaces, direcciones, rutas, DNS y sockets. Herramientas de la familia ip sustituyen a utilidades históricas en muchas distribuciones. ss permite consultar sockets.

ip address show
ip route show
ss -lntup
curl -v https://servidor/

Una prueba de conectividad debe realizarse por capas. Resolver un nombre no demuestra que el puerto esté abierto. Un puerto abierto no demuestra que TLS sea correcto. Completar TLS tampoco garantiza que la aplicación devuelva una respuesta funcional adecuada.

10.11. Almacenamiento

lsblk, df y du responden preguntas diferentes. df informa sobre utilización del sistema de ficheros montado, mientras du calcula utilización asociada a rutas.

lsblk -f
df -hT
du -xhd1 /var
findmnt

Un caso clásico aparece cuando un proceso mantiene abierto un fichero que ha sido eliminado del directorio. El espacio puede seguir ocupado mientras el descriptor permanece abierto aunque el fichero ya no aparezca mediante una búsqueda convencional.

10.12. Seguridad

SELinux o AppArmor pueden complementar los permisos tradicionales. Cambiar temporalmente a un modo menos restrictivo puede utilizarse para comprobar si una política interviene en una incidencia, pero la solución debe consistir en corregir contextos o reglas, no en dejar permanentemente el mecanismo desactivado.

La administración remota mediante SSH debe proteger autenticación, claves, algoritmos, privilegios, redes de origen y registro. Exponer directamente interfaces administrativas a redes no confiables incrementa notablemente el riesgo.

11. ADMINISTRACIÓN DE SISTEMAS WINDOWS

11.1. Identidades y SID

Windows utiliza Security Identifiers o SID para representar identidades y grupos. El nombre visible de una cuenta puede cambiar sin modificar necesariamente su identificador. Las ACL almacenan referencias a estas identidades.

En entornos de dominio, Active Directory proporciona identidades, grupos, equipos y políticas centralizadas. El acceso efectivo depende de pertenencias, privilegios, ACL, herencia y otras condiciones.

11.2. Servicios

El Service Control Manager administra servicios Windows. Un servicio tiene identidad, estado, tipo de inicio, dependencias y configuración de recuperación. Ejecutar todos los servicios mediante cuentas altamente privilegiadas aumenta el impacto de cualquier vulnerabilidad.

Get-Service
Get-Service -Name w32time
Restart-Service -Name w32time

11.3. Procesos

El Administrador de tareas, Resource Monitor y PowerShell permiten observar procesos. La utilización de CPU debe relacionarse con memoria, disco, red y comportamiento funcional.

Get-Process | Sort-Object CPU -Descending | Select-Object -First 10

11.4. Eventos

El Visor de eventos organiza registros del sistema, aplicaciones, seguridad y canales especializados. Un identificador de evento aislado no siempre proporciona suficiente información. Deben observarse proveedor, nivel, fecha, contexto y eventos relacionados.

Get-WinEvent -LogName System -MaxEvents 50

En entornos corporativos los eventos pueden reenviarse a sistemas centralizados. Esto facilita detección y análisis, pero requiere capacidad, sincronización horaria y políticas de retención.

11.5. Red

PowerShell y herramientas clásicas permiten consultar configuración y conexiones.

Get-NetIPConfiguration
Get-NetTCPConnection -State Listen
Test-NetConnection servidor -Port 443
netstat -ano

netstat -ano muestra información de conexiones y puertos, utiliza direcciones numéricas y añade el PID asociado. Un socket local en estado de escucha no demuestra por sí mismo que sea accesible remotamente: todavía pueden intervenir firewall, rutas, ACL y otros dispositivos de red.

11.6. Roles y características

Windows Server estructura determinadas capacidades mediante roles y características. Server Manager, PowerShell y Windows Admin Center proporcionan diferentes mecanismos de administración.

Server Core reduce componentes gráficos y puede disminuir superficie y mantenimiento, pero requiere compatibilidad de aplicaciones y herramientas. No debe elegirse únicamente porque sea «más seguro» sin analizar requisitos funcionales.

11.7. Directiva de grupo

Las GPO permiten aplicar configuración a equipos y usuarios dentro del entorno de dominio. El diseño debe considerar unidades organizativas, filtrado, precedencia, herencia y pruebas.

Una GPO aplicada de manera incorrecta puede afectar simultáneamente a un gran número de equipos. Por ello los cambios deben probarse previamente sobre grupos controlados.

11.8. Actualizaciones

Las actualizaciones deben coordinarse con ventanas de mantenimiento, reinicios, roles y disponibilidad. En un clúster o granja puede ser posible rotar nodos para conservar servicio, siempre que la arquitectura de aplicación lo permita.

11.9. BitLocker

BitLocker permite cifrar volúmenes Windows y puede integrarse con TPM y mecanismos de recuperación. La organización debe custodiar las claves de recuperación y verificar que la protección está realmente activada.

El cifrado protege frente a determinados escenarios de pérdida física, pero no evita que un atacante con acceso a una sesión válida pueda leer archivos de un volumen ya desbloqueado.

11.10. PowerShell

PowerShell trabaja principalmente con objetos y no únicamente con líneas de texto. Esto permite filtrar y transformar información utilizando propiedades conocidas.

$service = Get-Service -Name 'w32time'
if ($service.Status -ne 'Running') {
    Start-Service -Name 'w32time'
}

Los scripts corporativos deben controlar errores, registrar resultado, utilizar parámetros y evitar credenciales incrustadas. La automatización debe someterse a control de versiones y revisión.

12. PLANES DE IMPLANTACIÓN

12.1. Concepto

Un plan de implantación transforma una plataforma diseñada y probada en un servicio operativo. No es únicamente una secuencia de instalación. Debe coordinar requisitos, aplicaciones, usuarios, seguridad, datos, soporte, formación, comunicaciones, continuidad y criterios de aceptación.

12.2. Gobierno

El proyecto debe establecer responsables funcionales y técnicos, alcance, exclusiones, centros afectados, usuarios, criticidad y proceso de escalado. Infraestructura, comunicaciones, seguridad, aplicación y soporte deben conocer sus responsabilidades.

Una matriz de responsabilidades puede evitar situaciones en las que todos creen que una tarea pertenece a otro equipo. Este problema es especialmente frecuente con certificados, DNS, reglas de firewall, agentes o copias de seguridad.

12.3. Inventario y descubrimiento

Antes de implantar debe conocerse el entorno de origen: hardware, firmware, aplicaciones, drivers, periféricos, impresoras, certificados, tareas programadas, redes, identidades, scripts y datos.

Las herramientas automáticas deben complementarse con entrevistas y pruebas. Algunas dependencias se utilizan solo mensualmente o durante contingencias y podrían no aparecer en una observación breve.

12.4. Requisitos

Los requisitos funcionales determinan qué debe seguir funcionando. Los no funcionales incluyen rendimiento, disponibilidad, seguridad, privacidad, soporte y mantenibilidad.

Una matriz de compatibilidad puede clasificar cada elemento como soportado, soportado con cambio, pendiente de validación, sustituible o bloqueante. Cada bloqueo debe disponer de responsable y resolución.

12.5. Diseño objetivo

Debe definirse sistema operativo, edición, arquitectura, almacenamiento, cifrado, red, nombres, identidad, agentes, monitorización, actualización y recuperación. En puestos se especifica imagen o mecanismo de aprovisionamiento; en servidores, configuración de roles y servicios.

12.6. Línea base

La línea base describe el estado autorizado. Debe ser comprobable o automatizable. Si la configuración únicamente existe en un documento y nadie verifica el estado real, la deriva comienza desde el primer día.

12.7. Laboratorio

El laboratorio valida instalación y compatibilidad técnica básica. Debe intentar reproducir los elementos críticos de producción sin poner en riesgo el servicio real.

12.8. Piloto

El piloto introduce usuarios, equipos y situaciones reales con un alcance limitado. Debe seleccionar casos representativos, no únicamente usuarios expertos o equipos nuevos.

Las métricas pueden incluir porcentaje de instalaciones correctas, incidencias, rendimiento, compatibilidad de periféricos, tiempos de soporte y satisfacción funcional. Se definen criterios go/no-go antes de comenzar.

12.9. Estrategia de despliegue

El despliegue puede realizarse de una vez, por fases, centros, perfiles o anillos. Un cambio masivo reduce coexistencia pero concentra el riesgo. El despliegue gradual permite aprender y corregir problemas antes de afectar a todos los usuarios.

12.10. Comunicación

Los usuarios deben conocer qué cambia, cuándo y cómo solicitar ayuda. El soporte necesita procedimientos, herramientas y permisos antes de que comience el despliegue. Una campaña técnica sin preparación del soporte puede transformar pequeños problemas en una crisis operativa.

12.11. Corte y reversión

El plan de corte especifica secuencia, responsables y puntos de decisión. El rollback debe ser ejecutable dentro de la ventana prevista y considerar qué ocurrirá con los datos generados después del cambio.

12.12. Estabilización

Después del despliegue se monitorizan incidencias, rendimiento y cumplimiento. Las lecciones obtenidas deben incorporarse a imágenes, automatizaciones y base de conocimiento. Finalmente se retiran elementos temporales y plataformas antiguas cuando dejan de ser necesarias.

13. PLANES Y ESTRATEGIAS DE MIGRACIÓN

13.1. Concepto

Migrar significa trasladar aplicaciones, datos, identidades o servicios desde una plataforma origen hacia otra destino manteniendo los requisitos del servicio. Puede cambiar sistema operativo, versión, arquitectura, hardware, ubicación o modelo de operación.

La migración no consiste simplemente en copiar archivos. Deben conservarse integridad, autorizaciones, dependencias, operación, recuperación y soporte.

13.2. Estrategias principales

13.3. Actualización in-place

La actualización sobre la instalación existente conserva normalmente gran parte de aplicaciones, datos y configuración. Puede reducir trabajo, pero también arrastra configuraciones obsoletas y hace más difícil recuperar el estado exacto anterior.

La ruta debe estar soportada oficialmente. No todas las combinaciones de versiones, ediciones o roles admiten actualización directa.

13.4. Side-by-side

La estrategia side-by-side construye un entorno nuevo. Permite probarlo mientras el origen sigue disponible y facilita cambiar tráfico cuando se considera listo.

El coste es mantener temporalmente dos entornos y gestionar sincronización. Debe definirse cuál es el sistema autoritativo durante cada fase para evitar inconsistencias.

13.5. Dependencias

Deben inventariarse runtimes, bibliotecas, controladores, protocolos, certificados, cuentas, puertos y sistemas externos. Una aplicación de 32 bits puede disponer de compatibilidad en determinadas plataformas de 64 bits, mientras que un controlador en modo núcleo puede no disponer de equivalente.

13.6. Datos

La migración de datos define copia inicial, sincronización incremental, congelación de escrituras y validación. Las comprobaciones pueden utilizar recuentos, hashes, restricciones y pruebas funcionales.

Debe evitarse una situación en la que ambos entornos acepten escrituras independientes sin mecanismo de reconciliación. El punto de corte determina cuándo cambia la autoridad del dato.

13.7. Identidades y permisos

Los nombres visibles no bastan para preservar autorizaciones. SID, UID, grupos, ACL, certificados y cuentas de servicio pueden necesitar mapeo. Cambiar de dominio o mecanismo de autenticación puede afectar aplicaciones que almacenen identificadores internamente.

13.8. Pruebas

Las pruebas deben cubrir función, rendimiento, seguridad, backup, restauración, monitorización y operación. También debe probarse el procedimiento de recuperación en el destino.

13.9. Rollback

La reversión debe indicar condiciones de activación, responsable que toma la decisión, duración y tratamiento de los datos creados después del corte. Puede existir un punto de no retorno a partir del cual volver al origen resulte más arriesgado que continuar.

13.10. Migración Windows

En Windows Server la estrategia depende de versión, edición y rol. En determinados servicios puede resultar preferible desplegar servidores nuevos, incorporar el rol, validar, transferir funciones y retirar los anteriores en lugar de actualizar repetidamente el mismo sistema.

13.11. Migración Linux

Una actualización de distribución debe revisar repositorios, paquetes, archivos de configuración, servicios, módulos de kernel, políticas de seguridad y cambios en herramientas. Copiar indiscriminadamente un directorio /etc antiguo sobre una versión nueva puede introducir parámetros obsoletos o incompatibles.

13.12. Retirada

Una migración no termina hasta que el origen deja de ser necesario. Deben retirarse DNS, certificados, cuentas, licencias, monitorización, backups temporales y activos conforme al plan. Mantener plataformas antiguas indefinidamente aumenta superficie de ataque y coste.

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

14.1. Preparación

Antes de instalar deben comprobarse arquitectura, firmware, capacidad, controladores, soporte y licenciamiento. El medio debe obtenerse de una fuente autorizada y verificarse mediante mecanismos de firma o hash cuando el proveedor los facilite.

En instalaciones automatizadas, las plantillas y scripts deben versionarse exactamente igual que otro código de infraestructura.

14.2. Firmware y arranque

UEFI inicializa hardware y localiza el cargador de arranque. Secure Boot permite validar componentes de arranque firmados según las claves configuradas. La instalación debe definir de forma coherente modo de arranque y esquema de particiones.

Cambiar posteriormente determinadas configuraciones de firmware sin conocer cómo fue instalado el sistema puede impedir el arranque.

14.3. Particionado

Separar sistema, aplicaciones, datos, logs y temporales puede facilitar seguridad, recuperación y control de capacidad, pero no existe un esquema universal. La decisión depende de la carga y del almacenamiento disponible.

También deben definirse mecanismos de expansión. Tecnologías de gestión de volúmenes pueden aportar flexibilidad, pero no sustituyen backup ni monitorización.

14.4. Instalación mínima

Deben instalarse únicamente componentes necesarios. Cada servicio adicional incrementa mantenimiento y potencial superficie de ataque. En servidores suele evitarse software de usuario que no forma parte de la función del sistema.

Después de instalar se aplican actualizaciones, red, hora, identidad, agentes, monitorización y línea base de seguridad antes de exponer el servicio.

14.5. Red

La configuración incluye dirección, prefijo, gateway, DNS y, cuando proceda, VLAN o parámetros adicionales. Debe utilizarse la infraestructura DNS corporativa establecida.

Configurar servidores DNS públicos de forma indiscriminada en un equipo interno puede impedir resolver zonas corporativas y filtrar consultas fuera de la organización.

14.6. Sincronización horaria

La hora correcta es fundamental para autenticación, certificados, logs y sistemas distribuidos. Una plataforma aparentemente sana puede sufrir fallos de autenticación si mantiene un desfase excesivo.

14.7. Hardening inicial

La línea base deshabilita servicios innecesarios, configura firewall, restringe administración remota, aplica políticas de privilegio, habilita auditoría y protege almacenamiento y secretos.

Los secretos no deben almacenarse dentro de imágenes maestras o scripts. Una imagen clonada con credenciales embebidas multiplicaría el mismo secreto por todos los equipos.

14.8. Instalación de aplicaciones

Las aplicaciones deben ejecutarse con identidades dedicadas cuando proceda y separar binarios, configuración, datos y logs. Ejecutar permanentemente un servicio con privilegios administrativos porque «así funciona» incumple el principio de mínimo privilegio.

14.9. Optimización basada en medidas

Optimizar no consiste en modificar indiscriminadamente parámetros del kernel. El método correcto es establecer una línea base, identificar el cuello de botella, formular una hipótesis, aplicar un cambio controlado y volver a medir.

14.10. CPU

Se observan utilización por núcleo, colas de ejecución, cambios de contexto e interrupciones. En sistemas virtuales también puede existir contención relacionada con el hipervisor.

Aumentar la prioridad de todos los procesos no resuelve saturación. Si todo es prioritario, deja de existir diferenciación y aumenta la competencia.

14.11. Memoria

Se revisan memoria disponible, conjunto residente, cachés, fallos de página y actividad de intercambio. Una fuga debe localizarse en el proceso responsable; añadir RAM únicamente retrasaría el momento en que vuelva a agotarse.

14.12. Disco

Las métricas incluyen IOPS, caudal, latencia y cola. Una aplicación con pequeñas operaciones aleatorias requiere un análisis diferente al de una transferencia secuencial.

14.13. Red

Se diferencian ancho de banda, latencia, pérdida y retransmisiones. También debe observarse DNS: una aplicación puede parecer «lenta de red» cuando el verdadero problema es una resolución de nombres que tarda varios segundos.

14.14. Validación

La aceptación incluye versión, actualizaciones, servicios, identidad, red, almacenamiento, logs, seguridad, copia y restauración. Las imágenes maestras solo deben considerarse aprobadas después de superar estas comprobaciones.

La mejor optimización suele consistir en eliminar trabajo innecesario y corregir el verdadero cuello de botella. El tuning de bajo nivel es una herramienta posterior, no el primer recurso.

15. HERRAMIENTAS, AUTOMATIZACIÓN Y MONITORIZACIÓN

15.1. Herramientas locales

Las utilidades de línea de comandos permiten precisión, repetición y administración remota. En Linux son habituales ps, top, ss, ip, journalctl, df y du. En Windows se utilizan PowerShell, Event Viewer, Performance Monitor y Resource Monitor.

La herramienta debe elegirse según la pregunta. Un problema de CPU requiere datos distintos de uno de DNS o almacenamiento.

15.2. Administración remota

SSH, WinRM, PowerShell Remoting y otras herramientas permiten administrar sistemas sin acceso físico. Los canales deben estar cifrados, autenticados y restringidos a redes y usuarios autorizados.

Las interfaces administrativas no deben exponerse indiscriminadamente a Internet. En entornos críticos se utilizan segmentación, estaciones de administración, saltos controlados y registros.

15.3. Gestión de configuración

Herramientas como Ansible, Puppet, Chef, Salt o PowerShell Desired State Configuration permiten automatizar configuraciones. El objetivo es reducir variabilidad y reconstruir sistemas de forma reproducible.

Un concepto especialmente importante es la idempotencia. Una tarea idempotente puede ejecutarse repetidamente y, una vez alcanzado el estado deseado, no continúa introduciendo modificaciones innecesarias.

15.4. Despliegue

PXE, imágenes, secuencias de tareas, servicios de despliegue y mecanismos como cloud-init permiten automatizar instalaciones. Las imágenes gruesas incluyen gran cantidad de software, mientras un enfoque más ligero instala posteriormente componentes según función.

15.5. Monitorización

Una plataforma de monitorización debe medir servicio y experiencia, no únicamente que un host responde. Un servidor encendido puede contener una aplicación completamente inoperativa.

Las alertas necesitan severidad, deduplicación y una acción esperada. Si cualquier métrica genera continuamente alarmas, aparece fatiga y las alertas importantes dejan de recibir atención.

15.6. Centralización de logs

Los registros pueden enviarse a plataformas centralizadas y SIEM. La normalización de tiempo y campos facilita correlación. Debe existir suficiente capacidad y una política de retención acorde con requisitos y sensibilidad de los datos.

15.7. Diagnóstico avanzado

Volcados de memoria, trazas de llamadas, perfiles y capturas de red permiten investigar problemas complejos. Estas herramientas pueden afectar al rendimiento o capturar información sensible, por lo que deben utilizarse con alcance y duración controlados.

15.8. UEM

Las plataformas UEM amplían la administración centralizada a puestos y dispositivos móviles. Pueden gestionar inventario, configuración, aplicaciones y cumplimiento. No sustituyen herramientas de detección de amenazas como un EDR, aunque pueden integrarse con ellas.

15.9. Control de versiones

Scripts, playbooks y plantillas deben almacenarse en control de versiones, someterse a revisión y disponer de historial. Los secretos se obtienen de mecanismos protegidos y no deben incluirse directamente en el repositorio.

En operaciones masivas es aconsejable limitar concurrencia y desplegar por lotes. Un error que afecte a un equipo es una incidencia; el mismo error ejecutado automáticamente sobre miles de equipos puede convertirse en una caída corporativa.

16. SISTEMAS OPERATIVOS EN DISPOSITIVOS MÓVILES

16.1. Particularidades

Los sistemas móviles administran batería, sensores, radio, conectividad cambiante, suspensión frecuente y aplicaciones distribuidas mediante tiendas o sistemas empresariales. El dispositivo abandona habitualmente la red interna y puede perderse físicamente, por lo que el modelo de seguridad debe considerar escenarios diferentes de un servidor en un CPD.

La experiencia táctil y el consumo energético condicionan planificación, suspensión y ejecución en segundo plano. Las plataformas restringen determinadas actividades para prolongar autonomía y reducir abuso.

16.2. Android

Android utiliza el kernel Linux para procesos, memoria, controladores y mecanismos básicos de seguridad. Sobre él se sitúan HAL, bibliotecas nativas, Android Runtime, servicios de sistema, framework de API y aplicaciones.

Binder proporciona un mecanismo fundamental de IPC entre componentes Android. La HAL abstrae determinadas particularidades de hardware para evitar que el framework dependa directamente de cada implementación.

16.3. Sandbox Android

Android asigna normalmente un UID a cada aplicación y la ejecuta en un contexto separado. Las protecciones basadas en el kernel Linux constituyen la base del sandbox. SELinux añade control obligatorio y las aplicaciones solicitan permisos para acceder a capacidades protegidas.

El sandbox reduce impacto, pero no hace al dispositivo invulnerable. Una aplicación puede explotar una vulnerabilidad, abusar de permisos concedidos o engañar al usuario mediante ingeniería social.

16.4. Verified Boot

Android Verified Boot establece una cadena de confianza que verifica componentes del sistema durante el arranque y uso de particiones verificadas. Su objetivo es impedir o detectar determinadas modificaciones no autorizadas de componentes protegidos.

No sustituye el sandbox, los permisos ni la actualización. La seguridad móvil surge de la combinación de diferentes capas.

16.5. Actualizaciones Android

El mantenimiento depende del dispositivo, fabricante, modelo y programa de soporte. Para una compra corporativa no basta con valorar características hardware iniciales: deben considerarse años de actualizaciones y capacidad de administración.

16.6. iOS e iPadOS

Las plataformas de Apple se apoyan en Darwin y el kernel XNU, además de capas de servicios y frameworks. Integran estrechamente hardware, firma de código, arranque seguro, aislamiento y protección de datos.

El control centralizado del ecosistema facilita determinadas políticas de despliegue, aunque incrementa dependencia del proveedor y limita ciertos grados de personalización.

16.7. MDM, MAM, EMM y UEM

MDM se centra principalmente en administrar el dispositivo: inscripción, perfiles, certificados, Wi-Fi, VPN, cumplimiento, inventario, bloqueo y borrado. MAM se orienta a gestionar aplicaciones y sus políticas. EMM integra distintas capacidades de movilidad y UEM extiende la administración a múltiples clases de endpoint.

16.8. Modelos de propiedad

• COBO: dispositivo corporativo dedicado a uso profesional.
• COPE: dispositivo corporativo que permite cierto uso personal.
• BYOD: dispositivo propiedad del usuario.
• Kiosco o compartido: dispositivo destinado a una aplicación o utilizado por distintos profesionales.

El modelo condiciona qué puede controlar la organización y qué privacidad mantiene el usuario. En BYOD deben separarse adecuadamente información corporativa y personal. El borrado selectivo permite retirar datos gestionados sin eliminar necesariamente todo el dispositivo.

16.9. Seguridad móvil

Entre los controles relevantes se encuentran cifrado, bloqueo, autenticación, actualización, certificados, VPN, control de aplicaciones, acceso condicional y capacidad de respuesta remota. Rooting o jailbreak alteran el modelo de confianza y pueden justificar restricciones de acceso.

Ante pérdida física deben revocarse sesiones y credenciales además de bloquear o borrar el equipo. Localizarlo mediante GPS no sustituye estas medidas.

16.10. Ciclo de vida

La inscripción incorpora el dispositivo a la administración corporativa. Durante su vida se aplican políticas y actualizaciones. La baja debe retirar certificados, perfiles, aplicaciones y datos, actualizar inventario y ejecutar el tipo de borrado apropiado.

16.11. Movilidad sanitaria

Los dispositivos pueden utilizarse para consulta de información, captura, comunicaciones o autenticación. Los riesgos incluyen pérdida, visualización por terceros, redes inseguras, notificaciones sensibles y mezcla de información personal y corporativa.

17. APLICACIÓN EN EL SAS Y EL SSPA

17.1. El sistema operativo como parte del puesto de trabajo

En el Servicio Andaluz de Salud el sistema operativo debe entenderse como parte de una plataforma corporativa integrada. El puesto necesita conectarse con red, identidad, aplicaciones asistenciales y administrativas, certificados, impresión, periféricos y mecanismos de soporte.

Por ello una versión de sistema operativo no puede declararse válida únicamente porque arranque. Debe demostrarse que las aplicaciones funcionan, que los dispositivos necesarios disponen de soporte y que la plataforma puede administrarse de forma centralizada.

17.2. Estandarización

La estandarización reduce combinaciones de versiones, controladores y configuraciones. Esto facilita reproducir incidencias, desplegar actualizaciones, automatizar instalaciones y sustituir equipos.

Estandarizar no significa que todos los sistemas tengan que ser iguales. Un servidor, un puesto clínico, una tableta y un terminal especializado pueden necesitar plataformas diferentes. El objetivo es disponer de familias conocidas y gobernadas.

17.3. LeTSAS

LeTSAS constituye por tanto una referencia corporativa que ha sido objeto directo de examen. Debe distinguirse el nombre del producto de la tecnología sobre la que se construye una versión determinada.

17.4. Compatibilidad del puesto

Una migración del puesto debe probar navegadores, runtimes, certificados, autenticación, impresoras, lectores, escáneres, audio, vídeo, recursos compartidos y dispositivos específicos cuando proceda. La matriz de compatibilidad debe identificar qué elementos son soportados y cuáles necesitan sustitución.

Los casos minoritarios pueden convertirse en bloqueantes. Un dispositivo utilizado solo por una unidad concreta puede ser esencial para el proceso asistencial aunque represente un porcentaje mínimo del parque.

17.5. Identidad y red

El sistema debe recibir las políticas correspondientes, resolver correctamente nombres corporativos y mantener hora sincronizada. DNS y tiempo son dependencias básicas de mecanismos de autenticación, certificados y aplicaciones distribuidas.

Una estación puede iniciar correctamente y sin embargo quedar fuera del estado de cumplimiento porque no haya recibido políticas, no esté correctamente inventariada o no pueda comunicarse con servicios corporativos.

17.6. Despliegue por oleadas

En una organización extensa la implantación debe utilizar grupos controlados. Laboratorio, piloto y posteriores oleadas permiten detectar incompatibilidades antes de afectar masivamente al servicio.

Las métricas pueden incluir tasa de instalación, número de incidencias, tiempo de soporte, rendimiento y compatibilidad. Después de cada oleada deben actualizarse procedimientos e imágenes antes de continuar.

17.7. Soporte

El soporte necesita disponer de inventario, logs y base de conocimiento. La implantación no termina cuando se instala el último equipo. Existe una fase de estabilización en la que aparecen problemas menos frecuentes y deben cerrarse excepciones.

17.8. Movilidad

Los móviles corporativos salen de la red interna y pueden almacenar información sensible. MDM, MAM y UEM permiten aplicar configuraciones, certificados, VPN, cifrado, bloqueo, aplicaciones y acciones remotas.

17.9. Criterios de selección

Para una plataforma sanitaria deben considerarse soporte, compatibilidad, seguridad, automatización, observabilidad, integración con identidad, continuidad, coste total y conocimientos del equipo. Ningún criterio aislado resuelve la decisión.

La frase «funciona en mi equipo» tampoco constituye un criterio de aceptación. La plataforma debe poder instalarse, actualizarse, monitorizarse, restaurarse y retirarse mediante procedimientos repetibles.

18. MAPA CONCEPTUAL Y CLAVES DE EXAMEN

18.1. Distinciones fundamentales

• Programa / proceso: representación pasiva frente a instancia en ejecución.
• Preparado / bloqueado: espera CPU frente a espera de un evento.
• Concurrencia / paralelismo: progreso solapado frente a ejecución simultánea.
• Page fault / segmentation fault: evento que puede formar parte de la memoria virtual frente a acceso inválido.
• Sistema abierto / código abierto: estándares e interoperabilidad frente a derechos de licencia sobre el código.
• Contenedor / máquina virtual: kernel compartido frente a kernel invitado.
• Instantánea / backup: estado puntual frente a copia gobernada para recuperación.
• Alta disponibilidad / disaster recovery: reducción de interrupciones frente a recuperación tras pérdida grave.
• MDM / MAM: dispositivo frente a aplicaciones.

18.2. Perlas procedentes de exámenes

• UNIX: portable, multitarea y multiusuario.
• Linux: asociado históricamente a Linus Torvalds.
• /etc/shadow: almacena hashes de contraseñas locales.
• chmod 644: propietario rw, grupo r, otros r.
• Android: es un sistema operativo.
• LeTSAS: sistema operativo corporativo asociado a terminales ligeros del SAS.
• LeTSAS 7: dato histórico de examen asociado a Fedora 37.
• MDM y MAM: contenidos examinados en gestión de movilidad.

18.3. Método de resolución de preguntas

Ante una pregunta identifica primero el nivel al que pertenece la opción: hardware, kernel, servicio, aplicación o herramienta de administración. Después determina si se pregunta por un mecanismo, una política o un producto concreto.

Desconfía de absolutos como «siempre», «nunca», «garantiza completamente» o «sustituye a». Muchos controles de sistemas operativos reducen riesgos, pero no los eliminan. Un firewall no sustituye autenticación, un cifrado no sustituye backup y un MDM no sustituye EDR.