Seguridad

Cinco sistemas separados. Un modelo de privilegios.

Esta página está escrita para quien tiene que dar el visto bueno a HABLA^™: la dirección de tecnología, la asesoría jurídica del distrito, el cuestionario de seguridad que no le gusta a nadie. Cada afirmación de esta página se puede comprobar contra un esquema, una lista de privilegios o una ausencia declarada, y cuando una frase es un compromiso y no un control que ya está funcionando, la frase lo dice donde está. Una página de seguridad que mezcla esas dos cosas no le sirve de nada a quien la lee.

Solicite un recorrido guiado Lea el modelo de privacidad

En esta página

Todo esto se puede comprobar contra algo
Cinco sistemas separados
Qué puede hacer cada rol
Qué organización puede ver una sesión
La conservación es una columna, no una promesa
La identidad administrativa y la línea que no cruza
Qué guardan los registros

Todo esto se puede comprobar contra algo

La arquitectura de datos está construida, y usted puede pedir ver cualquier parte de ella. Las bases de datos están migradas, con sus roles, sus privilegios, sus políticas de fila y sus columnas de conservación en su sitio, y un paso de verificación lee esos privilegios de la base de datos en marcha y no de la migración que los pidió, porque una migración deja constancia de una intención y un catálogo deja constancia de un hecho.

Todo lo de aquí es una propiedad de un esquema, de una lista de privilegios o de una ausencia declarada. Eso es lo que lo hace comprobable: un privilegio está en el catálogo o no está, y usted puede pedir ver cualquiera de las dos cosas. En esta página no aparece ninguna cifra de disponibilidad ni de rendimiento: un número así vale algo en un acuerdo con un nivel de servicio detrás, y no vale nada en una página. Lo que HABLA corre en producción es este sitio web, junto con el proceso que hay detrás de su formulario de contacto y el proceso que hay detrás de su chat, y más abajo se cuentan y se describen.

Cuando una frase es un compromiso y no un control que ya está funcionando, lo dice donde está, al lado de la afirmación que matiza y no reunida en una nota al final —que es la nota que nadie lee en el momento en que habría importado.

La prueba útil para una página así: ¿puede quien la lee contrastar la afirmación con algo? Todo lo de aquí se contrasta con un esquema, con una lista de privilegios o con una ausencia declarada.

Cinco sistemas separados

No son esquemas dentro de una misma base de datos, ni una tabla con una columna que distinga a los clientes. Son bases de datos separadas, y eso es lo que hace que la separación sea otra cosa que una convención: los tres dominios de datos que describe el modelo de privacidad no pueden tener una llave foránea entre ellos, porque una llave foránea no cruza de una base de datos a otra.

Cinco sistemas separados y tres dominios de datos no es un error de cuentas. Un dominio es un corte de lo que HABLA puede saber de una persona, y de eso hay tres. Los dos últimos de esta lista no lo son: la capa entre organizaciones es donde se encuentran cifras de más de un cliente, y el almacén sellado guarda las cifras ya suprimidas de un periodo cerrado para que sobrevivan a los contadores de actividad anónima de los que salieron. Esta cuenta era cuatro hasta que se construyó el almacén sellado, y es parte de la afirmación: una página que enumera lo que una empresa opera tiene que corregirla aquello que la aumenta, que es la misma propiedad que lleva más abajo la cuenta de superficies que escriben registros, ya corregida dos veces.

Actividad anónima: Contadores, y nada más adentro. Un contador no es un historial de interacciones: una interacción suma uno a la fila cuyos valores coinciden con ella, junto a todas las demás interacciones que coincidieron con esos mismos valores, así que ninguna fila corresponde a la visita de una persona. La hora de una fila es una fecha de calendario y una hora entera: este almacén no guarda ninguna marca de tiempo exacta. Las columnas que servirían para describir a alguien no son columnas que tenga, así que no hay dónde ponerlas.
Contacto voluntario: Una tabla, con lo que alguien eligió dar cuando pidió que le respondieran y el destinatario que eligió alcanzar. Es lo más identificable que HABLA guarda, es el único almacén que guarda identidad, y es una base de datos separada de todas las demás de esta lista.
Configuración de la plataforma: El despliegue propio del cliente —sitios, paquetes de audiencia, colocaciones, la biblioteca de temas, los recursos, los destinatarios nombrados— junto con las cuentas administrativas que lo gestionan. El personal administrativo no es el público para el que existe el producto, y este almacén no guarda la identidad de ninguna persona de la audiencia. Desde la migración que los añadió guarda además aquello con lo que esas cuentas inician sesión: un resumen criptográfico de la contraseña, un secreto de segundo factor, códigos de recuperación de un solo uso, un registro de sesión y una cuenta de intentos fallidos, y ese contador va asociado a la cuenta y no a una dirección de red, cosa que vale la pena decir porque un limitador de intentos es la vía habitual por la que un sistema que prometió no guardar una dirección acaba guardándola. El personal administrativo no es el público para el que existe el producto, y este almacén no guarda la identidad de ninguna persona de la audiencia.
Agregados entre organizaciones: Su propia base de datos, a propósito, porque es el único lugar donde se encuentran cifras de más de un cliente. Recibe lo que un despliegue le envía y nunca consulta los datos propios de un cliente; y el desglose que recibe antes de publicar una cifra se rige por la misma regla que los contadores anónimos: ningún rol de lectura llega a él, y la compuerta de publicación ve cuántas organizaciones contribuyen, un total de eventos y dos cifras de concentración, nunca una fila.
Versiones de informe selladas: El almacén más nuevo, y también su propia base de datos. Cuando un periodo de reporte se cierra, las cifras que mostró un informe se escriben aquí una sola vez y no cambian nunca, para que un informe publicado un año siga resolviendo a las mismas cifras al siguiente, y para que una decisión registrada sobre esas cifras se pueda comprobar contra lo que de verdad se mostró. Una fila guarda una organización, un periodo, qué desglose es, y conteos que ya pasaron los dos umbrales: una celda que no los pasó se guarda sin ningún número dentro, y no con un número al que alguien pudiera llegar. Nada consulta una tabla aquí, y la sección siguiente dice qué puede hacer cada uno de sus roles. Todavía nada ha sellado un periodo, así que hoy está vacío.

Lo que mantiene separadas dos filas no es solo la llave que falta. HABLA no creó ninguna llave que emparejara una fila anónima con una de contacto, y nunca lo hará. Pero un grupo suficientemente pequeño de eventos contados, más la hora en que llegó una solicitud, estrecharía ese emparejamiento para quien pudiera leer los dos lados: así que el control que de verdad sostiene es el de la sección siguiente, donde nadie tiene lectura sobre el lado en bruto.

Y un residuo, dejado por escrito en lugar de explicado hacia otro lado. El motor de base de datos estampa sus propios números internos de versión en cada fila, que HABLA no declara y no puede quitar. Leerlos exige un privilegio de lectura a nivel de tabla que ningún rol de reporte, de ingreso o de borrado tiene. Esos números salen de un solo contador que comparte todo el servidor de base de datos, y las cinco bases de datos están hoy en un mismo servidor: así que el mismo valor creciente aparece en filas del almacén anónimo y en filas del almacén de contacto, y esa es la mitad de este residuo que matiza el párrafo de arriba en lugar de confirmarlo. Existe una rutina que reescribe esas filas para que esos números dejen de distinguirlas, y alcanza todas las filas, incluidas las del día de hoy; programarla es trabajo operativo que todavía tenemos por delante, es un control dentro del almacén anónimo y no hace nada con el contador compartido. Y no alcanza a una copia. Un respaldo, una réplica o la propia bitácora de escritura del servidor llevan los números originales sin importar de qué lado de esa rutina se tomen, junto con el momento exacto en que se escribió cada fila. Así que quién puede leer esas copias es un control operativo y no uno de la base de datos, y preferimos decirlo a dejar que la rutina se lea como un arreglo que no es.

Bases de datos separadas en un mismo servidor son una garantía más débil que servidores separados, y si producción puede compartir uno es una decisión abierta y no una decisión tomada. Está anotada como abierta.

Qué puede hacer cada rol

Una vista que esconde los valores pequeños es medio control. La otra mitad es el privilegio, porque un rol que puede leer la tabla de abajo simplemente lee la tabla. Así que la pregunta interesante nunca es qué vistas existen: es qué puede tocar cada credencial.

El camino que escribe actividad no tiene ningún privilegio de lectura: Registrar una interacción significa insertar en una vista de solo escritura, y el incremento ocurre dentro de una rutina que pertenece a quien es dueño del esquema. Al rol que ingresa actividad no se le concede ningún privilegio sobre las tablas que hay detrás de esas vistas: ni lectura, ni inserción, ni actualización. Nunca necesita leer lo que escribe, así que no puede.
Para leer una cifra hay que pasar por las vistas de supresión, y solo por ellas: La credencial que sella un periodo de reporte cerrado tiene lectura sobre las cinco vistas que ya aplicaron el umbral de diez eventos de actividad, y el trabajo que envía el total de una organización al almacén entre organizaciones tiene lectura sobre una de ellas. Ningún otro rol de este almacén tiene lectura de ningún tipo, y ningún rol tiene lectura a nivel de tabla sobre las tablas de contadores que están debajo. Una supresión que viviera solo en la aplicación no sobreviviría a un script de soporte ni a una consulta improvisada; un privilegio revocado sí.
El umbral es una constante guardada, sin lugar donde poner una excepción: El umbral vive en la base de datos como una función que no recibe ningún argumento: no hay una organización que pasarle, ni una credencial que consultar, ni una tabla donde pudiera aparecer una columna con un umbral por cliente. Esa es la forma exigible de una negativa que HABLA ya hizo por escrito: un umbral que se vende por dinero no es un umbral, y la forma del código es lo que impide que se convierta en una sola instrucción de actualización.
Cada umbral se exige en un sitio distinto, y esta página dice en cuál: El umbral de diez eventos de actividad está en la propia base de datos, y lo de arriba es cómo se sostiene ahí. El umbral de población de cincuenta personas no está en ese almacén, y no puede estarlo: en los contadores anónimos no hay ninguna columna que nombre una población cubierta, a propósito, porque a cuánta gente cubre una colocación es un dato sobre el mapa de la propia organización y no sobre quien haya tocado algo; vive en el almacén de configuración, al otro lado de un límite que ninguna consulta cruza. Se aplica donde las dos cosas se juntan: en el programa que compone y sella las cifras de un periodo cerrado, que es lo único de este sistema que lee ambas. Una colocación o un paquete de audiencia que cubre a menos de cincuenta personas no tiene fila propia allí, y su actividad se suma al nivel de arriba en vez de estrecharse hacia una persona.
El rol de borrado ve las columnas por las que borra, y ninguna otra: El rol que ejecuta ahí la conservación tiene borrado sobre las tablas de contadores más lectura sobre las columnas que necesita su condición de borrado, y sobre ninguna otra: nunca sobre un conteo. Se dice exacto, porque un residuo que nadie nombra es un residuo que nadie revisa: puede saber qué combinaciones de organización, tema y fecha existen. No puede saber cuán grande es ninguna de ellas. Esa es la forma de este almacén y la más amplia de las cinco; la del almacén sellado es la más estrecha y va debajo.
En el almacén sellado, los roles que existen para tocar una cifra son los que no pueden leer ninguna: En este almacén no hay ninguna vista, y el rol que le responde a quien lee no tiene ningún privilegio sobre sus cuatro tablas: solo puede llamar a una rutina, que no recibe ninguna coordenada, así que no se puede pedir una celda suelta y llega un desglose entero o no llega ninguno. El rol que escribe una versión sellada no puede volver a leer una cifra que escribió: sella todas las organizaciones en una sola pasada, así que una credencial capaz de releer lo suyo podría enumerar las cifras selladas de todos los clientes en una. El rol que ejecuta aquí la conservación tampoco tiene privilegio sobre ninguna tabla, y su barrido no recibe ningún argumento —ni fecha de corte, ni organización—, así que no hay forma de borrar una cifra sellada antes de tiempo ni de barrer solo la de un cliente.
En el almacén de contacto, escribir y leer son roles distintos: El rol que registra una solicitud de contacto tiene inserción y ninguna lectura. El rol que la trabaja tiene lectura, y puede actualizar las columnas de flujo que el flujo necesita y ninguna más. El rol que supervisa la cola llega a una vista y no tiene ningún privilegio sobre la tabla.
Y la propiedad del esquema, que es la parte honesta: PostgreSQL le da a quien es dueño de una tabla privilegios que no se pueden revocar de forma duradera, así que «ningún rol puede leerla» es una afirmación sobre los roles con los que se conecta un sistema en marcha. El control sobre esa propiedad es que su credencial no vive en ningún servicio en ejecución: eso es un control operativo, y llamarlo control operativo en lugar de privilegio es la diferencia entre una afirmación comprobable y una que no lo es.

Algo a lo que esa forma no se extiende, dicho aquí y no dejado por supuesto: en el almacén de configuración, los roles que leen la configuración propia de un cliente leen sus tablas de forma directa. Ese almacén no guarda datos de personas de la audiencia, y al rol de lectura no se le concede nada sobre las ocho tablas que sí guardan personas: el personal administrativo, los destinatarios nombrados y quienes revisan contenido, más las cinco que aparecieron cuando el personal administrativo pudo iniciar sesión — sus credenciales, sus segundos factores, sus códigos de recuperación, sus sesiones y el contador de intentos fallidos. Decía tres hasta el día en que se creó la quinta, y la cuenta forma parte de la afirmación: una página que enumera lo que una credencial no puede alcanzar tiene que corregirse cada vez que se añade algo nuevo que esa credencial pudiera alcanzar.

Y exactamente lo que eso no compra, porque una tabla no es una persona. El rol de lectura sí llega a una vista de las decisiones registradas de la organización, y esa vista resuelve a quien queda como responsable de una decisión en una etiqueta que, cuando esa responsable es una persona, es el nombre de alguien del personal administrativo. Así que la frase exacta es que la credencial de lectura no puede consultar la tabla del personal administrativo y aun así lee ahí el nombre de una persona administradora. Es lo mismo que el registro de funcionalidades ya dice del Action Center. Decir en cambio que esas personas están fuera del alcance de la credencial de lectura sería cierto sobre las tablas y engañoso sobre las personas, y una página de seguridad es el peor lugar del sitio para hacer ese cambio.

Y un segundo alcance, que es una tabla y no una vista, escrito aquí porque si no el párrafo de arriba se leería como si fuera todo. Este almacén guarda referencias a personas del personal administrativo en filas que tratan de otra cosa, y hay cuatro tablas así y el rol de lectura las lee todas: quién retiró un contenido, quién escribió y quién publicó una de sus versiones, qué persona revisora lo aprobó, quién declaró la banda de población de un despliegue y —desde la migración que añadió la vigilancia permanente de un tema— quién la abrió. Nadie ha abierto ninguna, y el privilegio es el que es en cualquier caso. Cada una de esas cosas es un identificador en lugar de un nombre. La tabla que guarda los nombres sigue siendo aquella sobre la que la credencial de lectura no tiene ningún privilegio, y la única vista nombrada arriba sigue siendo el único sitio donde convierte un identificador en un nombre. Lo que sí puede saber sin un nombre es que la misma persona hizo estas cosas y otra distinta hizo aquellas.Solo la última de las seis apareció con esa migración. Las otras cinco llevaban siendo ciertas más tiempo del que lleva existiendo este párrafo, y lo que estaba mal era que esta página no lo dijera y no el privilegio en sí: “ningún privilegio sobre las ocho tablas” invita a concluir que nadie del personal administrativo aparece en nada de lo que lee la capa de informes, y esa conclusión no es cierta.

Qué organización puede ver una sesión

Cada tabla del almacén de configuración lleva una política de fila, y la tabla de solicitudes de contacto también. Una sesión declara para qué organización está actuando, y cada fila de datos de cliente que puede leer o escribir es de esa organización. En ese almacén hay un conjunto pequeño y nombrado de filas que no pertenece a ninguna organización, y los párrafos siguientes dicen cuáles: una página que enunciara la regla y dejara fuera sus excepciones deliberadas estaría describiendo una base de datos que HABLA no tiene.

Los datos del cliente fallan cerrado. Toda política sobre las filas propias de un cliente comprueba la declaración, así que una sesión que no ha declarado una organización no lee ninguna de ellas: ni las de otra organización, ni ninguna. Se le muestran cero filas en lugar de mostrárselo todo, y esa es la propiedad que vale la pena comprobar en cualquier sistema que dice aislar a sus clientes, porque el valor por defecto contrario es el que produce el incidente.

Hay tres tipos de fila que a propósito no pertenecen a ninguna organización, y aquí se nombran en lugar de dejar que alguien las encuentre. El contenido que HABLA le entrega a todo despliegue —la biblioteca de temas, los recursos, y las versiones y los registros de revisión que cuelgan de ellos—, que cualquier cliente puede leer y ninguno puede escribir. La copia que este almacén guarda de los cuatro umbrales sobre los que está construido el producto, que toda credencial que lee este almacén puede leer y ninguna puede cambiar. Y las cuentas del servicio de comparativas, que son de HABLA y de ningún cliente. Sus políticas sí coinciden con una sesión que no ha declarado nada, a propósito: en esas filas no hay nada de un cliente que una declaración pueda estrechar, y un «una sesión sin declarar no coincide con ninguna fila en ningún sitio» sería falso sobre todas ellas.

Y la credencial de borrado tiene un segundo modo que es entre organizaciones por diseño. Con una organización declarada es la cascada de borrado de ese cliente y está confinada a él. Sin nada declarado es el barrido de conservación, y alcanza exactamente las filas cuyo propio anclaje de conservación ya venció —una persona administradora, un destinatario nombrado o quien revisa contenido ya desactivados, un registro de decisión pasado su periodo, una solicitud de contacto pasado el suyo— en todas las organizaciones a la vez, porque un barrido al que hay que decirle qué cliente barrer es un barrido que alguien tiene que acordarse de ejecutar. El registro de una persona administradora todavía en servicio queda fuera del alcance de esa credencial en cualquiera de los dos modos. De vida corta hay dos que no, y aquí se nombran en lugar de dejar que alguien las encuentre: una sesión caducada y un contador de intentos fallidos ya vencido pertenecen a personas administradoras que siguen en servicio, y el barrido las quita. Sobre esas dos la credencial no tiene ningún privilegio —menos aún que sobre las tablas que sí barre—, porque esa limpieza corre dentro de una rutina que pertenece a quien es dueño del almacén y no a través de una concesión propia. Y una sesión no puede estar en los dos modos a la vez.

Y esto es exactamente lo que compra. Hacer cumplir la regla dentro de la base de datos vuelve obligatoria la declaración en todos los caminos hacia el almacén, incluidos el script de soporte y la consulta improvisada que un control en la aplicación nunca ve. Lo que no puede es hacer que la declaración sea verdadera: la sesión declara su propia organización, así que el límite real es lo que se interponga entre una persona administradora ya autenticada y esa declaración, y eso es la consola de administración, que ahora sí está construida y no la puede alcanzar nadie. El aislamiento se hace cumplir en la base de datos; la autenticación que decide quién puede hacer esa declaración está escrita, y nunca ha respondido a una petición de fuera de la máquina donde se construyó.

Las políticas de fila hacen trabajos distintos en almacenes distintos, y en dos de los cinco están ausentes. Ni los contadores anónimos ni el libro entre organizaciones le conceden a ningún lector una lectura de tabla, así que no hay lectura que una política pueda estrechar. Una política ahí sería un adorno en una puerta ya soldada.

El almacén sellado no encaja en ninguna de las dos formas, y contarlo de cualquiera de las dos maneras sería falso. Tiene políticas de fila en todas sus tablas y ninguna de ellas le deja a nadie leer una cifra. Gobiernan la escritura —qué periodo se puede sellar, y solo después de que haya cerrado— más una única lectura del registro que no guarda ninguna cifra, para el único rol que necesita saber si ya existe una versión. La ausencia es la parte que se diseñó: con la seguridad a nivel de fila encendida y sin política de lectura sobre las cifras, conceder después una lectura devolvería cero filas hasta que alguien escribiera también una política. Eso es una segunda línea, en un segundo archivo, debajo del párrafo que explica por qué no la hay: un segundo cerrojo puesto a propósito, y no uno que falte.

También hay una salvaguarda sobre el borrado en cascada que comprueba qué identidad está ejecutando, en vez de confiar en una bandera que pone quien llama: una bandera que cualquiera puede poner es una convención de nombres, no una salvaguarda.

La conservación es una columna, no una promesa

Cada tabla que guarda datos derivados de una persona está anclada a una columna sobre la que puede actuar un trabajo de borrado —la propia, o, cuando la vida entera de una fila es la de otra fila, la de esa otra— y a un periodo documentado o a un estado documentado que la termina. Ancladas de la segunda manera hay tres, y aquí se nombran en lugar de dejarlas dentro de la palabra «cada»: lo que usa una persona administradora para iniciar sesión. Una regla de conservación sin una columna detrás no se puede revisar, así que HABLA la trata como ausente y no como regla.

Actividad anónima: veinticinco meses, por fecha.
Las cifras que mostró un informe cerrado, selladas para que un informe siga resolviendo a lo que mostró: setenta y dos meses, contados desde el primer día del periodo. Es otro reloj, distinto al de la actividad anónima de arriba, y lo único que fija su duración es esto: seis años es la vida más larga que este sistema le da a un registro que pudiera citarlas, así que una cifra sellada dura exactamente lo que dure la decisión más longeva capaz de señalarla, y ni un mes más. Lo que se guarda es un total que un informe ya publicó —uno que ya había superado los umbrales antes de escribirse, con todo lo que quedaba por debajo ya retirado—, de modo que los contadores de los que salió pueden irse en su propia fecha sin llevárselo consigo. Esa fecha la calcula la base de datos a partir del propio periodo y no se la toma a quien escribe, así que no se puede alargar: ni por un ajuste, ni por un argumento al trabajo de borrado, ni por una sentencia posterior.
El registro de qué versiones se sellaron, que no guarda ninguna cifra —solo el periodo, una huella de lo que se mostró y el momento en que las cifras se fueron—: ciento cuarenta y cuatro meses, seis años más que las propias cifras. Esa diferencia es la única regla de esta lista cuyo propósito es sobrevivir a lo que describe, y su duración no se eligió: son los setenta y dos meses que duran las propias cifras más la vida más larga que este sistema le da a un registro que pudiera citarlas —seis años, que es el límite exterior que la propia base de datos se niega a sobrepasar—. Una decisión registrada en la consola de la propia organización puede citar una versión sellada mientras ese registro se conserve, así que, cuando las cifras ya no estén, HABLA prefiere responder que no se conservan y decir cuándo se fueron a no responder nada: una ausencia no le dice a quien lee cuál de las dos cosas pasó. En el mismo reloj y también sin ninguna cifra: la constancia de un intento rechazado de sellar por segunda vez un periodo ya cerrado.
Una solicitud de contacto: noventa días por defecto, escritos cuando se hace la solicitud, y un contrato puede fijar otro periodo por esa misma columna.
Una persona administradora, un destinatario nombrado o quien revisa contenido: noventa días desde el día en que se desactiva la cuenta, no desde el día en que se creó.
Lo que usa una persona administradora para iniciar sesión —el verificador de contraseña, el secreto de segundo factor y los códigos de recuperación de un solo uso—: se destruyen en el instante en que la cuenta se desactiva, no noventa días después. La ventana que HABLA le da al registro de quién fue alguien no es una ventana para lo que le permite entrar. Estas son las ancladas en una fila madre: la columna es la de la cuenta, a un salto de distancia, borrar la cuenta las borra, y una columna propia se podría fijar más allá de la de la cuenta.
La sesión de una persona administradora ya autenticada: no se conserva. La termina el reloj que primero se agote de los tres: doce horas desde que se creó, como máximo; treinta minutos de inactividad; o una revocación por cierre de sesión, cambio de contraseña, restablecimiento del segundo factor, cambio de los roles que tiene la cuenta o desactivación. Una sesión terminada se rechaza en el momento en que se presenta, esté o no borrada su fila, y quitar la fila es el mismo programa sin programar que todo lo demás de esta lista. El almacén no tiene dónde guardar un historial de inicios de sesión, y eso es deliberado.
El contador de intentos fallidos de inicio de sesión: quince minutos, y la fila se va cuando han vencido tanto la ventana de conteo como cualquier bloqueo de la cuenta. Un inicio de sesión correcto la borra del todo en vez de ponerla a cero, porque una fila a cero sigue diciendo que alguien tuvo problemas para entrar. Hay una fila por cuenta, con un conteo y el instante en que se abrió la ventana: ninguna fila por intento, ninguna hora del día, ninguna dirección.
El registro de una decisión de la organización: el historial contratado, y tres años donde ningún contrato fija otro —y nunca más allá de seis años desde el día en que se tomó la decisión, porque la base de datos rechaza una fecha más lejana en vez de fiarse del programa que la escribe. Ese límite exterior es contra el que se mide el registro de arriba, así que ningún registro puede sobrevivir a la evidencia que cita.
El registro de consultas que sostiene las comprobaciones de integridad: ciento veinte días, escritos como la ventana de presupuesto más el periodo de revisión hacia atrás y no como una cifra redonda.
La constancia de que un borrado ocurrió: sin caducidad, a propósito; cada campo suyo habla del borrado y no de nadie, y es la única evidencia de que el borrado se llevó a cabo.
El libro previo a la publicación del almacén entre organizaciones, que guarda cuánto aportó cada despliegue a una cifra: sin periodo y sin temporizador, a propósito; sus filas se borran cuando la cifra a la que pertenecen se publica o se rechaza, que es un estado y no una duración. Es la única regla de esta lista que es una transición de estado, y darle un plazo de gracia sería inventar una ventana de conservación que ningún documento concede.

Lo que no está hecho, junto a lo que matiza. Los trabajos de borrado están escritos —cinco, uno por almacén— y no hay nada que programe ninguno. Cada uno se conecta con una cuenta de base de datos estrecha que no lleva contraseña en ninguna parte del código fuente de este repositorio —a propósito, porque una credencial en un archivo fuente es una credencial en el repositorio—, y hasta que esas cuentas existieron esa era una segunda razón por la que ninguno podía arrancar. Se provisionaron fuera de banda; cuatro se crearon a la vez y la quinta llegó con el almacén que la necesitaba, así que ya no es una credencial que falta lo que los detiene; lo que los detiene es que nada los programa, y esta página lo dice en vez de dejar en pie la razón vieja. Lo que un periodo sí impone hoy es un límite de lectura, y la forma honesta de decirlo dice dónde: en una solicitud de contacto, pasado su instante, las políticas de fila esconden la fila de todo rol de aplicación, así que queda ilegible y sigue ahí. La sesión de una persona administradora llega al mismo efecto por otra vía —la rutina que busca una sesión rechaza la que ya pasó su caducidad o la ventana de inactividad— y el contador de intentos fallidos no tiene ese límite ni lo necesita, porque una ventana vencida no cuenta como nada para lo único que la lee. Un límite de lectura es un control real y no es un borrado, y decir cuál es cuál es el punto de este párrafo. Automatizarlos es trabajo operativo que todavía tenemos por delante, y hasta entonces la frase exacta es que las reglas existen y son exigibles, no que el borrado sea automático.

La identidad administrativa y la línea que no cruza

Una persona administradora es personal de la organización, con nombre y correo de trabajo, y eso vive en el almacén de configuración junto a los sitios y las colocaciones. No está en la misma base de datos que nada de lo que produce el lado de la persona, y no hay camino de una a la otra.

No hay ninguna columna que apunte al otro lado. Nada en el almacén de configuración hace referencia a los contadores anónimos; los contadores llevan los valores de configuración del propio despliegue, y ningún valor que describa a la persona que los produjo; y son bases de datos separadas, así que una llave entre ellas no es algo que una migración futura pudiera añadir por descuido. No hay ningún enlace entre bases de datos configurado en ninguna de las dos direcciones, y una comprobación verifica que no aparezca.

La identidad administrativa no está permitida en la experiencia de la persona, y eso sigue siendo un compromiso y no algo que se pueda leer en un catálogo. La experiencia en la que aparecería ya está construida, y eso cambia la frase en vez de reforzarla: ya no es cierta solo porque no haya código. La forma honesta es la que da el modelo de amenazas —ningún camino así está permitido, y cualquiera que apareciera sería un hallazgo Crítico y no una cuestión de diseño—, con la diferencia de que el código del que habla ahora existe y se puede leer. Lo que hoy se puede comprobar en un catálogo de base de datos es el párrafo de arriba.

El personal administrativo también son personas, y así se les trata. Sus filas llevan una fecha de desactivación y la misma regla de borrado a noventa días que cualquier otro dato derivado de una persona, que es la parte de un modelo de administración que normalmente no tiene ninguna regla.

La autenticación en sí está construida y no la puede alcanzar nadie, y aparece más abajo con todo lo demás que está en ese estado, en vez de describirse como si estuviera en servicio.

Qué guardan los registros

La telemetría existe para mantener sana la infraestructura, y un registro que le permita a alguien reconstruir el recorrido de una persona es un defecto, sea cual sea el motivo por el que se recogió. La regla en sí, y los emparejamientos que un registro nunca debe llevar juntos, está en la página de privacidad. Lo que corresponde aquí es la evidencia, partida en la mitad que se ha comprobado y la mitad que no.

Comprobado

Las superficies de HABLA que escriben registros en esta máquina son hoy cuatro. En el camino de una petición que hace quien visita están el servidor de origen que sirve este sitio web, el proceso que hay detrás del formulario de consulta de la página de contacto y el proceso que hay detrás de HABLA AI, el chat. La cuarta es el gestor de bases de datos PostgreSQL, y está aquí porque la prueba que este párrafo le aplica a la consola de administración —si está instalada, si hay un puerto escuchando— también lo admite a él. Además, cada vez que se ejecutan, escriben una línea una copia diaria del repositorio y una actualización semanal de la lista de direcciones del borde de red a las que el origen responde, y se nombran aquí en lugar de dejar que alguien las encuentre. Ninguna de ellas escribe la dirección de quien visita, y cada una de las cuatro se comprueba aquí en sus propios términos, no cubierta por una frase sobre las otras.

Ese conteo es parte de la afirmación, y ya ha estado mal dos veces. Decía doshasta que el chat entró en servicio, y tres hasta que se contó la base de datos: una página que enumera lo que una empresa opera tiene que corregirla lo que se le sume. Las dos correcciones salieron de alguien que leyó la página contra la máquina, y eso es el punto débil y no la parte tranquilizadora: el número se mantiene a base de atención y no de una prueba. Queda escrito como un hueco abierto: falta algo que se ponga en rojo el día en que esta máquina gane un proceso. La consola de administración sigue sin volverlo cinco, y esa razón es comprobable y no tranquilizadora: no está instalada en esta máquina y ningún puerto escucha por ella. El día en que se ponga en servicio, este número es una de las cosas que tienen que cambiar con ella.

El servidor de origen. El registro de peticiones está apagado a nivel de servidor y no en un solo bloque, así que un bloque añadido después no hereda un valor por defecto que las escriba. Los dos campos de dirección están quitados del propio formato de registro, así que un registro que alguien volviera a encender no podría reintroducirlas por descuido. Los registros de error se descartan en lugar de guardarse, porque el formato de error estampa una dirección en cada entrada de petición. Y el módulo que resolvería la dirección de quien visita por detrás del borde de la red está deliberadamente sin configurar, así que este servidor no la resuelve nunca. El bloque de configuración que sirve el formulario de consulta no declara ningún registro propio, así que hereda todas esas reglas en lugar de partir de un valor por defecto.

El proceso del formulario de consulta. La dirección de quien visita se usa aquí y en el chat, y en ningún otro punto de HABLA. Este proceso escribe dos tipos de línea: la dirección en la que queda escuchando cuando arranca y —cuando un mensaje no llega al buzón— qué paso de la conversación de correo falló y con qué código respondió el servidor de correo. Ninguno de los dos lleva un campo que alguien haya escrito, ni la dirección de quien envía. La dirección se convierte en cambio en una clave de límite de frecuencia: un resumen criptográfico de ella, calculado con un valor aleatorio que el proceso genera al arrancar y olvida al detenerse, guardado en memoria junto a un conteo durante esa ventana y que no se escribe en ningún archivo ni en ninguna base de datos. El proceso no tiene ninguna conexión a base de datos, así que no hay dónde escribirla. Y el código que guarda el conteo solo recibe una clave y un reloj, así que no podría poner esa clave junto a un nombre, una dirección o un mensaje aunque alguien se lo pidiera.

HABLA AI. El chat es un segundo proceso de la misma forma, y se leyó de la misma manera en lugar de quedar cubierto por el párrafo anterior. Escribe dos tipos de línea: la dirección en la que queda escuchando cuando arranca, junto con los nombres de los archivos de documentación que cargó, y —cuando algo falla— qué etapa falló y, si el rechazo viene de quien opera el modelo, el código de estado que respondió. Ninguno de los dos lleva una conversación, un turno, un campo que alguien haya escrito ni la dirección de quien visita. La dirección se convierte en una clave de límite de frecuencia con el mismo código que usa el formulario de consulta: el mismo resumen criptográfico bajo un valor aleatorio nuevo en cada arranque, el mismo conteo en memoria durante la ventana, sin escribirse en ningún archivo ni en ninguna base de datos. Este proceso tampoco tiene conexión a base de datos. Lo que aquí es distinto, y se dice en lugar de dejar que se descubra, es que la conversación misma sale de la infraestructura de HABLA: se envía a Anthropic para escribir cada respuesta. Qué significa eso, en detalle, en la página de privacidad.

El gestor de bases de datos. PostgreSQL corre aquí porque las bases de datos se construyen y se prueban en esta máquina. Escucha en la interfaz local de esta máquina y en ninguna otra, así que una conexión solo puede abrirse desde dentro de esta misma máquina. Ninguno de los procesos a los que llega quien visita lleva credencial de base de datos ni controlador de base de datos, y ninguna línea de código de ellos nombra uno, así que ninguno puede abrir esa conexión en nombre de quien visita. No está en el camino de ninguna petición que sirva este sitio web. Lo que escribe es lo que escribe una base de datos cuando algo sale mal: el texto de la sentencia que falló y el detalle que va debajo. Las sentencias que salen bien no se escriben, las conexiones y desconexiones tampoco, y cada línea lleva una marca de tiempo y un número de proceso y ninguna dirección de cliente. Todo camino que llega hasta él empieza dentro de esta máquina, en trabajo de desarrollo o de pruebas, así que lo que hay en ese archivo no vino de alguien usando HABLA: esa es la afirmación que hay que comprobar el día en que esta página se lea contra un producto en marcha.

Ese es el punto del diseño en las tres superficies a las que llega una petición: la promesa se sostiene por construcción —un módulo dejado sin configurar, un valor aleatorio nuevo en cada arranque— y no por un ajuste de conservación que alguien tiene que acordarse de mantener. La cuarta es distinta y vale la pena decirlo con claridad: una base de datos escribe lo que escribe una base de datos, y lo que mantiene fuera a quien visita es que no hay camino que lleve de una petición hasta ella.

No comprobado

Los servicios que HABLA configura pero no escribe —el borde de la red, una CDN, un servicio de seguimiento de errores— y todas las superficies que todavía no están en servicio, incluida la consola de administración. Hay una auditoría completa de registros programada y no se ha hecho.Esa segunda mitad dice no están en servicio y ya no no existen, a propósito. Antes decía lo segundo, y esa redacción es la que dejó que un proceso operado por HABLA entrara en servicio mientras los dos registros seguían describiendo el mundo anterior: algo que existe pero no está corriendo también pertenece a este lado de la línea, y un apartado que solo admite cosas que no existen no tiene dónde ponerlo.

Su resultado es vinculante en las dos direcciones. Si encuentra que un servicio que HABLA no puede apagar guarda detalle por petición, lo que cambia es la afirmación publicada, no la redacción para que quepa el hallazgo. Eso está escrito de antemano como la consecuencia, que es el único momento en que una regla así se puede escribir con honestidad.

Pregunte por la parte que suene demasiado fuerte.

Una lista de privilegios, una política de fila y una columna de conservación son cosas que se le pueden mostrar a alguien paso a paso. Si una frase de esta página no se le puede mostrar así, no debería estar en esta página, y esa es la conversación que vale la pena tener antes de un contrato y no después.

Solicite un recorrido guiado Cómo cuenta HABLA