Un conjunto de documentación interna privada (notas de infraestructura, runbooks, el tipo de cosas que escribes para tu yo futuro a las 2 de la madrugada durante un incidente) se mantiene completamente separado de este sitio público. Nunca se fusiona, nunca se convierte en plantilla para una entrada, nunca se referencia por ruta. Esa separación no es incidental; es la razón por la que cada una de estas entradas del log existe en la forma en que existe, describiendo decisiones y trade-offs reales sin describir la infraestructura real sobre la que se tomaron esas decisiones.
Cada una de estas veinte entradas viene de algún sitio. Algunas son razonamiento de arquitectura casi puro que puedo escribir directamente. Otras empezaron como una nota privada sobre algo que realmente se rompió, o una decisión que realmente se tomó, y tuvieron que pasar por un paso real de clasificación antes de que nada de eso se convirtiera en un párrafo en una página pública. Ese paso es el verdadero tema de esta entrada: no lo que hay en las notas privadas, sino la disciplina de decidir qué es seguro decir en voz alta.
La pregunta equivocada y la correcta
El instinto al revisar material privado para reutilización pública es preguntar “¿es esto un secreto?”. Es la pregunta equivocada, porque invita a una respuesta estrecha y técnica (una contraseña es un secreto, un chiste interno no lo es) y la mayor parte de lo que realmente importa vive en medio. “No es un secreto, es solo un detalle interno” es la frase que hace que la gente publique el párrafo equivocado, porque secreto implica algo formalmente clasificado, y la mayoría del detalle identificable nunca fue formalmente nada. Simplemente es específico.
La pregunta que realmente clasifica el material de forma correcta es: ¿esto le facilita el trabajo a un atacante, aunque sea un poco, sin ningún beneficio para el lector?
Ese enfoque hace dos cosas que la pregunta de “es un secreto” no hace. Primero, sopesa coste frente a beneficio en lugar de comprobar una etiqueta binaria: una IP real no le cuesta nada al lector perderla (la lección no depende de cuál era esa IP), pero podría costar algo si se filtra, así que falla el test aunque nadie llamaría “secreto” a una dirección IP en el sentido de credenciales. Segundo, se escala hacia abajo hasta detalles que a nadie se le ocurriría proteger individualmente: una convención de nombres de host interna concreta, la estructura exacta de directorios de un conjunto de documentación privada, en qué puerto escucha una interfaz de gestión. Ninguno de esos es un secreto. Cada uno de ellos es un pequeño regalo gratuito para quien esté construyendo un mapa de tu infraestructura, y el lector no pierde nada si los generalizas.
Lo que nunca aparece, lo que se abstrae, lo que está bien tal cual
Tres cajones, y la mayor parte del trabajo real está en clasificar correctamente entre el segundo y el tercero, más que en atormentarse con el primero: el primer cajón suele ser obvio en cuanto te fijas en él.
Nunca aparece, punto: credenciales de cualquier tipo, nombres de host e IPs reales, URLs de uso interno, identificadores de hardware y números de modelo, cualquier cosa que estreche el espacio de búsqueda de un atacante para un sistema que sigue existiendo y funcionando tal como describe la nota. Este cajón no se “generaliza”: se elimina, porque no existe una versión del detalle concreto que sea a la vez precisa y segura de publicar.
Necesita abstracción antes de ser utilizable: la forma real de la mayor parte del material operativamente interesante. “Un entorno de producción gestionado” en lugar de una IP o un nombre de host reales conserva toda la lección (así gestionamos un fallo, este fue el trade-off que hicimos) mientras elimina el único detalle que permitiría a un lector que no es la audiencia prevista usar la entrada como reconocimiento en lugar de como escritura. Este es el cajón que exige criterio, porque la abstracción puede fallar en ambas direcciones: demasiado poca, y solo has renombrado la filtración; demasiada, y has abstraído lo que hacía que la entrada mereciera la pena leerla. “Un servicio tuvo una caída” sin ningún otro detalle no enseña nada. “Un servicio en una capa de red concreta perdió conectividad cuando un proveedor upstream concreto tuvo un problema de enrutado, y el arreglo fue X” enseña algo, y nada de esa frase necesita un nombre de host real para ser cierta y útil.
Está bien publicarlo tal cual: el razonamiento en sí. Por qué se tomó un trade-off, cuáles eran las alternativas, qué se rompió y por qué, qué cambió realmente el arreglo en la arquitectura. Nada de eso necesita detalle identificable para merecer la pena leerlo: si acaso, el detalle identificable normalmente diluye la lección, porque la IP concreta nunca fue la parte interesante de la historia.
Por qué esto es una disciplina, no una auditoría
El modo de fallo de tratar esto como una auditoría puntual es obvio en cuanto lo dices en voz alta: revisas un documento una vez, decides que es seguro, y luego sigues escribiendo frases nuevas en contextos que ya diste por revisados. Una nota que era precisa y segura de forma aislada deja de ser segura en el momento en que se combina con otras tres notas ya revisadas que, juntas, reconstruyen algo que ninguna de ellas exponía por separado. La clasificación tiene que ocurrir en el punto de uso (cada vez que material privado se convierte en texto fuente para algo público), no en algún punto anterior, cuando el material privado se escribió por primera vez.
Eso es una práctica más pesada de lo que suena, porque significa que la comprobación se ejecuta en cada entrada, cada charla, cada herramienta liberada como open source, no solo en la primera. Es la misma razón por la que una revisión de seguridad de un sistema no es algo que haces una vez y luego confías para siempre: el sistema cambia, y con él cambia qué significa “seguro de exponer” para él. Las notas privadas detrás de este sitio se actualizan con regularidad; un detalle que hace seis meses estaba bien abstraer y publicar puede describir hoy una arquitectura que ya no existe, lo cual en realidad lo hace más peligroso de reutilizar sin cuidado, no menos: un detalle desfasado puede llevar a un atacante a un esfuerzo desperdiciado, cierto, pero igual de fácilmente puede describir una debilidad que ya se arregló de una forma que la entrada pública nunca menciona, dejando a los lectores con un modelo mental obsoleto de un sistema que en realidad ya es distinto.
Lo que esto significa para una entrada como esta
No voy a describir la estructura de la documentación privada, sus nombres de archivo, ni lo que realmente dice sobre ningún sistema concreto: hacerlo aquí sería exactamente el fallo contra el que argumenta esta entrada, usando esta misma entrada como ejemplo. Lo que sí puedo decir con honestidad, porque es solo una descripción de la práctica y no del material: cada entrada de esta colección que toca algo operativo pasó por este filtro antes de hacerse pública. Una entrada como la brecha de backups que esta plataforma no ha cerrado es exactamente el tipo de admisión que esta disciplina tiene que acertar: un riesgo real, con nombre, sin ninguno de los detalles reales de infraestructura que lo harían útil para nadie que no sea el lector. Algunas ideas no sobrevivieron a esto en una forma que mereciera la pena publicar, y eso está bien: una lección que no se puede contar sin el detalle identificable que la hace peligrosa es una lección que se queda privada. Eso no es un fallo del proceso de escritura. Es el proceso funcionando como se pretendía.
La parte incómoda de esta disciplina es que nunca produce un “terminado” satisfactorio. No hay una lista de comprobación que completes una vez y archives. Cada entrada nueva es una nueva instancia de la misma pregunta, formulada de nuevo, sobre material que sigue cambiando debajo de ti. Eso no es un defecto del método: es lo que significa tratar tus propias notas como material que en algún momento informará algo público, de forma consistente, en lugar de como una fuente que explotas una vez y dejas atrás.
Un repaso práctico, no una intuición
Decir “pregúntate si ayuda a un atacante sin beneficio para el lector” es el test correcto, pero aplicarlo bien necesita más estructura que sostener la pregunta vagamente en la cabeza mientras ojeas un borrador. En la práctica, un repaso real sobre una entrada candidata implica unos pocos movimientos concretos, hechos en orden y no todos a la vez.
El primero es una lectura llana buscando cualquier cosa que parezca un identificador: cualquier cosa que permitiera a alguien relacionar esta entrada con un sistema real concreto si se pusiera a buscar. Eso incluye las categorías obvias (IPs, nombres de host, credenciales) pero también las menos obvias: un mensaje de error distintivo copiado y pegado literalmente de un log real, una marca de tiempo lo bastante precisa como para correlacionarla con otra información pública, una captura de pantalla con el título de una ventana o una ruta de archivo visible en una esquina. Las capturas de pantalla son una forma especialmente fácil de filtrar algo que la prosa que las rodea nunca menciona, porque el detalle identificable viaja dentro de la imagen en lugar de en algo que se corrija como texto.
El segundo movimiento es preguntar, para cada detalle concreto que quede, si la frase sigue enseñando su lección al sustituir ese detalle por un marcador genérico. Si “el servicio corría en una pieza de hardware concreta en un rack concreto” se convierte en “el servicio corría en hardware dedicado” y el punto real del párrafo (contención de recursos, una decisión de capacidad, lo que fuera) sobrevive intacto a esa sustitución, el detalle de hardware concreto nunca estaba haciendo trabajo real en el texto. Simplemente había quedado ahí del material fuente porque así es como la nota original describía las cosas, no porque la versión pública lo necesitara.
El tercer movimiento, y el más fácil de saltarse bajo presión de tiempo, es leer el borrador terminado una vez más como si fuera la única información pública que tiene el lector, no como el autor que ya conoce el contexto privado. Ese cambio de perspectiva capta cosas que los dos primeros repasos se pierden, porque es el único punto del proceso en el que estás comprobando efectos de combinación: ¿esta entrada, leída junto a las otras diecinueve, empieza a esbozar un esquema de la infraestructura privada que ninguna entrada individual revela por sí sola? Esa pregunta solo tiene alguna posibilidad de recibir una respuesta real si se formula desde el punto de vista del lector, no del autor.
Una abstracción que mantiene la lección honesta
Hay un modo de fallo al otro lado de esta disciplina que merece la pena nombrar, porque es tan real como la infrarredacción: abstraer de forma tan agresiva que la entrada deja de ser cierta en ningún sentido útil. “Un sistema tuvo un problema y lo arreglamos” es seguro e inútil. El objetivo no es la máxima vaguedad: es encontrar el nivel concreto de descripción que conserva el contenido técnico real (qué se rompió, por qué, qué cambió el arreglo, qué trade-off se hizo) mientras solo elimina las coordenadas que permitirían localizar el sistema real detrás de él. Es un objetivo más estrecho que “sé vago”, y acertarlo de forma consistente es la mayor parte de lo que esta disciplina realmente es en la práctica, entrada tras entrada.