¿Quién puede acceder al código fuente, la canalización y el entorno de producción?
El control de acceso en el desarrollo de software se refiere a la pregunta de quién puede realizar qué acción en qué parte de su cadena de desarrollo: quién puede leer código, quién puede modificar y fusionar código, quién puede iniciar una compilación y quién puede desplegar una versión en producción. Es una pregunta más específica que el control de acceso en una organización en general, porque un equipo de desarrollo trabaja con varios sistemas al mismo tiempo: un repositorio de código fuente, un entorno de compilación y prueba, y generalmente un entorno de producción separado donde el software funciona realmente.
La razón por la que este tema reaparece en cuestionarios de seguridad y en las medidas de gestión del riesgo de la Directiva NIS2 es que un error en el control de acceso a su cadena de desarrollo se transmite directamente a todos los que utilizan su software. Quienquiera que pueda modificar código sin ser detectado y luego implementarlo afecta no solo a su propia organización sino también a sus clientes. Por eso tanto una autoridad supervisora como un cliente que a su vez está sujeto a la obligación de gestión del riesgo pregunta cómo ha organizado esto.
Por qué se trata específicamente del código fuente y la canalización
Un equipo de desarrollo generalmente tiene más personas con derechos más amplios de los estrictamente necesarios, simplemente porque funciona en la práctica: todos pueden acceder a todo, nadie tiene que esperar a nada. Desde la perspectiva de la obligación de gestión del riesgo, ese es exactamente el punto que se cuestiona. No porque la confianza fuera incorrecta, sino porque la comprobabilidad es diferente de la confianza: una autoridad supervisora o un cliente quiere saber si puede demostrar quién tiene acceso, no solo si confía en ello.
Las preguntas que suelen surgir aquí se refieren a tres niveles. El primero es el propio repositorio de código fuente: quién puede leer, quién puede modificar, y ¿hay una verificación obligatoria antes de que un cambio se fusione con la versión principal? El segundo es el entorno de compilación y prueba: quién puede iniciar una compilación, y ¿tiene ese entorno acceso a datos o sistemas que no están destinados a propósitos de prueba? El tercero es el entorno de producción: quién puede desplegar realmente una versión, y ¿es ese un grupo diferente de personas que quienes escriben el código?
Separación entre escribir e implementar
Una distinción recurrente en los cuestionarios es si la persona que escribe el código es también quien implementa la versión en producción. Cuando es la misma persona, sin una revisión intermedia de otra persona, surge una situación en la que un error o un cambio malicioso llega a producción sin ser detectado. Muchas organizaciones resuelven esto mediante una segunda revisión obligatoria antes de fusionar el código, y con un rol separado o derechos separados para la implementación real. La forma en que esto se ve en la práctica varía mucho según el equipo y el tamaño; la directiva en sí no prescribe una forma de proceder específica, pero las autoridades supervisoras y los clientes sí examinan la pregunta subyacente: puede una sola persona implementar cambios incontrolados que afecten a los clientes.
Secretos y claves separados del código
Un segundo punto sobre el que los cuestionarios suelen preguntar regularmente es dónde se almacenan las contraseñas, las claves de API y otros secretos. Los secretos que están en el código fuente en sí son visibles para todos los que tienen acceso de lectura a ese código, lo que puede ser un grupo mucho mayor que quienes realmente deberían trabajar con esa clave. Un almacén separado para secretos, con sus propios derechos de acceso independientes del repositorio de código, es una forma habitual de hacer esa separación. Si e cómo organiza esto es una elección técnica; lo que es relevante para el expediente es principalmente si puede explicar por qué el enfoque elegido es apropiado para el tamaño y los riesgos de lo que está construyendo.
Lo que documenta, no solo lo que configura
La configuración técnica de los derechos de acceso es una cosa; demostrarla es otra, y en la práctica esa segunda se olvida más a menudo. Una lista de quién tiene acceso a qué sistema, cuándo se otorgó, y sobre qué base, es precisamente la prueba que un cuestionario o una autoridad de supervisión solicita. Sin esa lista debe resolver cada pregunta de nuevo; con un registro dinámico junto a cada medida, la respuesta ya está lista. revisar la explicación por medida proporciona una idea de cómo la gestión del acceso se relaciona con las otras nueve medidas del deber de diligencia.
Si su organización cae bajo el deber de diligencia, o si recibe esta pregunta porque un cliente sí lo hace, se puede determinar con algunas preguntas. Para quién se pregunta qué tan estrictos son exactamente los requisitos de gestión del acceso cuando un cliente solicita demostrar qué se ha regulado, la explicación sobre protección y seguridad de datos proporciona una visión más amplia de dónde provienen este tipo de requisitos.
Para la situación particular, por ejemplo si un arreglo específico de su línea de desarrollo es suficiente para el deber de diligencia que pesa sobre usted o su cliente, un abogado o la autoridad de supervisión competente es el lugar indicado; secria.eu prepara el registro pero no emite pronunciamiento sobre el cumplimiento individual.
¿Desea ver cómo encaja la gestión del acceso en el resto de su expediente, o tiene preguntas adicionales sobre qué se entiende exactamente con esta medida? leer las preguntas más frecuentes proporciona respuestas breves en muchos de esos puntos, y el análisis rápido gratuito muestra en unos pocos minutos dónde se encuentra su organización en este tema.