Como desarrollador junior, he estado trabajando en un proyecto durante 4 meses. Mi proyecto se ha configurado a través del sistema de control de versiones TFS, mientras que el proyecto de mi compañero de equipo está configurado por SVN. El proyecto está en mantenimiento, por lo que no hay trabajo regular allí. Sin embargo, cuando nuestro cliente envía una solicitud de cambio, la mayoría de las veces soy yo mismo quien hace el cambio, después de las pruebas unitarias y el registro del código fuente en TFS. Nuevamente, es mi responsabilidad enviar esos cambios a mi compañero de equipo, que es superior a mí, quien lo revisará e implementará el código en producción.
Le pedí a mi superior que me entregara el acceso FTP para el sitio de producción, por lo que cada vez que se requiera un cambio, lo liberaré a PROD bajo las siguientes condiciones:
Es reacio a entregarme el acceso FTP. Una vez le pregunté a nuestro líder sobre este tema, pero el líder de nuestro equipo también permaneció en silencio.
Mis preguntas:
¿Qué debo tener en cuenta antes de solicitar acceso al sitio de productos?
¿Cómo hago un caso comercial para que se me otorgue acceso a PROD como respaldo en caso de que mi colega no esté disponible repentinamente en aras de la continuidad del negocio?
No lo tomes como algo personal o como un insulto. Probablemente no tenga nada que ver con tu competencia como desarrollador.
Hay ciertas responsabilidades que están reservadas para gerentes, líderes de equipo y personas mayores; la principal responsabilidad es el acceso a los sistemas de producción/en vivo. Dar acceso a un sistema crítico a un desarrollador junior probablemente vaya en contra de la política de la empresa y, en general, no sea una buena práctica. Es una buena idea hacer que su código pase por un desarrollador más senior solo para verificar el código y asegurarse de que nada se rompa. La empresa reduce sus posibilidades de que un código incorrecto se convierta en producción al limitar la cantidad de personas que tienen la capacidad de implementarlo.
Asume que el desarrollador senior tiene la autoridad para otorgarle acceso al servidor de producción.
En muchos entornos de desarrollo, eso no es cierto. Trabajo con empresas en las que ninguno de los desarrolladores tiene acceso al back-end de los servidores de producción. Solo el equipo de seguridad y el equipo de administración de sistemas tienen acceso a los servidores a nivel SSH. Los desarrolladores pueden usar un sistema de implementación automatizado para enviar cambios a los servidores de producción, pero solo después de que el equipo de seguridad haya revisado los cambios de código propuestos y fusionado la rama adecuada en la rama de producción.
Una regla de oro en seguridad, como dice Peter, es que si no tienes acceso, nunca se te puede culpar.
El hecho de que (en términos prácticos) puedan permitirle este tipo de acceso no significa que deban hacerlo . Dejando a un lado todas las tonterías: hay una razón por la que las empresas hacen una distinción entre "junior" y "senior". Como desarrollador junior, se espera que cometas muchos errores y descuidos. Ninguno, de la persona mayor que está describiendo, su líder, y sus jefes, y los jefes de sus jefes se arriesgarán a poder pagar sus hipotecas a cambio de hacerlo sentir más seguro en su posición allí.
Con el debido respeto, cualquier tonto con acceso FTP puede dejar archivos en un servidor. Ni siquiera se necesita un usuario técnico, solo alguien con una copia de Filezilla, un nombre de host, un nombre de usuario y una contraseña. Muchas empresas han experimentado interrupciones debido a que los desarrolladores junior están ansiosos por demostrar su valía. Por lo tanto, le dan acceso para realizar una implementación "registrada", pero ¿qué le impide intentar corregir errores "extraoficialmente", cosas que quizás no sepa cómo deshacer, y hacer que las cosas vayan de mal en peor? ? ¿Por qué deberían confiar en ti? Solo han pasado cuatro meses, y lleva mucho más tiempo sentir el estilo de hacer las cosas de un miembro del personal. Realmente nadie tiene tiempo para explicarte esto, razón por la cual no has recibido una respuesta.
En este punto, tome una pastilla para relajarse. Haz lo mejor que puedas en los deberes que se te asignen. Brilla con lo que ya tienes. Dentro de un año más o menos, verás a más desarrolladores junior entrar por la puerta detrás de ti; y si ha prestado buena atención en el trabajo en los casos en los que la mierda golpea al ventilador y la gente busca mantener la atención negativa lejos de ellos, comprenderá este paradigma mucho, mucho mejor.
Como alguien que trabaja en la profesión de seguridad de TI, hay muy buenas razones que explican el comportamiento de su superior. Los 2 conceptos más relevantes son
Segregación de deberes
El director de SOD establece que las funciones incompatibles deben ser realizadas por 2 o más personas para minimizar la colusión y las vulnerabilidades de seguridad. El desarrollo de código (lo que hace actualmente) y la publicación de código (lo que quiere hacer) son tareas incompatibles en la mayoría de las circunstancias. Un desarrollador que tenía acceso a producción podía desarrollar código, incrustar código malicioso, como puertas traseras o bombas lógicas, en código legítimo y luego liberar el código a producción sin ser detectado. Dicha actividad es extremadamente riesgosa para el negocio, y la mayoría de las empresas no pueden permitirse la pérdida de recursos críticos de TI. Si los datos en los que se trabaja son extremadamente confidenciales, la supervivencia del negocio podría estar en duda.
Privilegios mínimos
El principio de privilegio mínimo establece que un usuario solo debe tener los privilegios mínimos necesarios para realizar sus tareas laborales y no más . Este concepto también está estrechamente relacionado con la tríada de seguridad de la CIA . Seguir esta práctica minimiza el riesgo de que un usuario abuse de los recursos de TI u obtenga poderes de administrador/superusuario no autorizados sobre un sistema, donde él o ella puede hacer básicamente cualquier cosa que quiera, como:
Destruir datos: violación de la integridad y posible disponibilidad
Denegar acceso a usuarios legítimos - Violación de disponibilidad
Divulgar datos a terceros no autorizados - Violación de la confidencialidad
Tu trabajo como desarrollador junior es escribir el código fuente. No parece que incluya la liberación a PROD. Por lo tanto, su superior está siguiendo las mejores prácticas de seguridad al negarle el acceso.
Cómo hacer que Business Case se realice como respaldo para cambios de emergencia en PROD
Habiendo dicho lo anterior, debe haber una persona de respaldo que pueda hacer comunicados en vivo en caso de que su superior no esté disponible. La continuidad del negocio se ve afectada si solo 1 persona puede realizar una tarea en particular, un riesgo importante para la administración más razonable. Sin embargo, antes de presentar su caso, debe verificar los sistemas de registro utilizados para auditar los cambios en el entorno de producción.. Si no tiene esto, o si lo tiene pero no está monitoreado, o monitoreado pero sin un plan de respuesta a incidentes para responder a la detección de cambios no autorizados en la producción, entonces hay problemas mayores en su empresa. Si puede asegurar a la gerencia que las solicitudes de cambios de emergencia realizadas por los desarrolladores se registran de forma segura para que los cambios puedan revisarse y los cambios no autorizados se puedan rastrear hasta la persona responsable, entonces su caso de que se le otorgue acceso a PROD aumenta mucho más. Para que un registro de auditoría se defina como seguro, se deben cumplir las siguientes características:
El acceso al registro se mantiene al mínimo número de usuarios que tienen la necesidad de conocer su contenido. - Confidencialidad
Las entradas de registros se bloquean al confirmarse, por lo que los cambios posteriores no pueden modificar las entradas de registros escritas anteriormente. - Integridad
Se asocia una identificación de usuario única para cada usuario que realiza un cambio junto con una marca de tiempo para indicar cuándo se realizó el cambio. - No repudio
Para arrojar más información sobre lo que puede suceder cuando los derechos de acceso son descuidados, eche un vistazo a lo que sucedió con el OP en estas dos preguntas:
Como todavía es un desarrollador junior, es posible que su senior no haya tenido suficiente confianza en usted debido a los riesgos de errores en el entorno de producción en vivo. Esto no debe tomarse como algo personal, ya que su experiencia crecerá con el tiempo que pase en su empresa. También debería ser algo reconfortante para usted saber que sin acceso, si algo saliera mal, no sería sospechoso, dado que nunca podría haber accedido a la producción, incluso si hubiera querido.
Pueden ser reglamentos.
En mi trabajo como desarrollador me está expresamente prohibido tener acceso a los entornos de producción. Esta es una medida de seguridad. Los que hacen el software no deberían ser las personas que lo ponen en producción porque entonces existe la posibilidad de un conflicto de intereses.
Normalmente, el que tiene acceso es el responsable si las cosas van mal.
Idealmente, debido a que el senior aprueba los cambios y los implementa, se le culpará si hay problemas.
Ahora puede intentar darte acceso, pero eso no le quitaría la culpa. En lugar de eso, te permitiría hacer lo que quisieras, y si la cagas, sigue siendo su culpa.
Eso debería explicar por qué no quiere darte acceso.
¿Qué debo tener en cuenta antes de solicitar acceso al sitio de productos?
Lo principal que debe considerar es el riesgo de que cuanto más presione para obtener acceso, mayor será la preocupación de que esté demasiado interesado en obtenerlo y lo use en exceso o abuse de él de alguna manera. ¿Realmente se puede confiar en usted para usar el acceso directo solo en emergencias, o podría comenzar a pasar por alto los controles normales innecesariamente?
¿Cómo hago un caso comercial para que se me otorgue acceso a PROD como respaldo en caso de que mi colega no esté disponible repentinamente en aras de la continuidad del negocio?
Necesita saber qué hacer si su colega no está disponible repentinamente y se necesitan cambios en el servidor. Si no lo sabe, debe preguntar al respecto ahora, no esperar hasta que surja la situación.
Darle acceso directo es solo una de las posibles respuestas, y no una particularmente probable. Por ejemplo, puede haber uno o más suplentes, que no están involucrados en el flujo normal pero que podrían hacer una actualización si fuera necesario. O tal vez los cambios pueden esperar a su colega o un reemplazo.
Si intenta convertirlo en un caso comercial para el acceso directo, eso puede obstaculizar la solución del problema real de no saber qué hacer en esa situación.
Creo que debe profundizar en su razonamiento y descubrir cómo esto beneficia al cliente. Pídele a tu jefe que aclare que está bien retrasar la aplicación de las actualizaciones. Tal vez los clientes entiendan esto o la naturaleza de su negocio no sea tan sensible al tiempo. Asegúrese de que su jefe comprenda los riesgos.
En el peor de los casos, el cliente está esperando/necesita desesperadamente la solución. ¿Se supone que debes decirles que no va a suceder porque tu jefe no está disponible? Si no, qué mentira sugiere.
Alguien de la empresa debería sufrir las consecuencias y no creo que debas ser tú, pero serás el portador de malas noticias.
Brandín
Mandy
usuario44108
TrabajadorDrone
patricia shanahan
Hombre enmascarado
usuario42272
Migz
gnasher729
Adam Smith
laurent s.