Control de acceso (Access control)

Toda decisión de acceso tiene las mismas tres partes: un sujeto que pide, un objeto sobre el que pide y una operación. La implementan dos componentes. Un punto de decisión evalúa la política y responde sí o no; un punto de aplicación se sitúa en el camino de la petición y se niega a actuar sin esa respuesta. Separarlos es lo que permite que muchos servicios apliquen una misma política de forma coherente.

Los modelos se diferencian en dónde vive la regla. El control discrecional deja que el propietario del objeto conceda acceso a él. El control obligatorio aplica una regla para todo el sistema que el propietario no puede saltarse. El control basado en roles asocia permisos a roles y roles a identidades. El control basado en atributos evalúa atributos del sujeto, del objeto, de la acción y del contexto en el momento de la petición. Los parques reales mezclan los cuatro, y por eso nadie puede responder quién tiene acceso a qué sin consultar varios sistemas.

El fallo que produce la mayoría de nuestros hallazgos es aplicar el control en el sitio equivocado. Un control implementado en la interfaz que genera la petición es una comodidad de uso. Si el servidor atiende cualquier petición que le llega, el punto de aplicación no existe, y esconder un botón no cambia nada. Cada opción de menú que se le quita a un rol tiene detrás un endpoint que sigue estando ahí.

El segundo es permitir por defecto. Un sistema que consiente todo lo que no esté denegado expresamente está a una regla olvidada de quedar expuesto, y la regla olvidada es siempre el endpoint nuevo, el bucket nuevo, la cola nueva. Denegar por defecto falla cerrando y se nota de inmediato.

El tercero es la deriva. Los permisos se acumulan: la gente cambia de equipo y conserva el acceso antiguo, los proyectos terminan y el grupo sobrevive, una concesión de urgencia no se revoca nunca. Nadie retira accesos porque nadie tiene la certeza de qué se va a romper, así que el parque avanza siempre en la misma dirección, y eso es lo que convierte el mínimo privilegio en una disciplina de operación y no en una configuración.

Lo probamos con una identidad real en la mano, pidiendo lo que no le corresponde en todas las capas a las que llegamos: la interfaz, la API que hay detrás, el almacenamiento que hay detrás de esa y el plano de gestión que hay detrás de todo. El hallazgo nombra el sujeto, el objeto, la operación y la capa donde debía estar la comprobación y no estaba. El control de acceso roto es de forma sistemática la categoría más grande de nuestros informes de aplicación, y casi nunca es una funcionalidad que falte: es una comprobación colocada una capa demasiado arriba.