Protección del entorno de desarrollador para Confianza cero
Este artículo le ayuda, como desarrollador, a proteger el entorno de desarrollo para que pueda implementar Principios de confianza cero (compruebe explícitamente, use el acceso con privilegios mínimos, asuma la vulneración). Incluye contenido de nuestro libro electrónico Protección de entornos de Enterprise DevOps y resalta los procedimientos recomendados para la seguridad de las ramas y las herramientas de confianza, las extensiones y las integraciones.
La velocidad del desarrollador se basa en la capacidad de trabajar como y donde desea maximizar los resultados empresariales. Quiere máquinas eficaces y personalizables con acceso raíz o de administrador. Sin embargo, las demandas del desarrollador pueden ejecutarse de manera contraria a las normativas de cumplimiento y la necesidad de auditar y controlar el acceso y el almacenamiento del entorno de los empleados privados.
Máquinas no administradas que se conectan a los equipos de seguridad, la adquisición y la junta de gobernanza del desafío de la red de la organización. El mejor escenario de proporcionar a los desarrolladores entornos de empleados predeterminados y protegidos crea desdén en ambos lados. Cuando los empleados se conectan desde cualquier lugar, las redes Wi-Fi vulnerables son una puerta abierta para el ciberataque. El robo y la pérdida de hardware son problemas importantes.
Las vulnerabilidades se extienden a las integraciones del entorno de desarrollo. Las herramientas de desarrollo que incluyen una extensibilidad enriquecida pueden tener integraciones no detenidas en sus marketplaces. Las extensiones malintencionadas pueden poner en peligro las herramientas de desarrollo y provocar vulneraciones en toda la empresa.
En el siguiente diagrama, observe cómo el entorno de desarrollo se conecta al entorno de herramientas de DevOps para afectar a las ramas de Git. Amplía la superficie del entorno a través de la conexión a paquetes de código abierto y extensiones de aplicación. Las extensiones presentan vectores de ataque en vulnerabilidades de aplicaciones de dependencia y extensión.
Proporcionar a los miembros del equipo de DevOps flexibilidad y control al tiempo que evita ataques malintencionados es un desafío fundamental para las oficinas de seguridad. DevOps puede controlar el entorno de desarrollo con un entorno de nube (consulte Inicio seguro para máquinas virtuales de Azure y la Documentación de GitHub Enterprise Cloud) y proteger el entorno de desarrollo con contenedores (consulte la Documentación de GitHub Codespaces).
Además, los desarrolladores pueden implementar estas medidas de confianza cero para ayudar a proteger el entorno de desarrollo:
- Configurar privilegios mínimos.
- Limitar quién puede cambiar y aprobar código con seguridad de rama.
- Adoptar solo herramientas, extensiones e integraciones de confianza.
Procedimientos recomendados para privilegios mínimos
A menudo, los desarrolladores creen que pueden detectar malware, suplantación de identidad y vulneraciones en sus entornos. Las superficies de amenazas del entorno de desarrollo de gran tamaño hacen que los desarrolladores no sean realistas para mantener el conocimiento omnipresente del sistema. Una organización pierde un tiempo de corrección precioso cuando detecta una infracción después de un ataque pone en peligro un entorno de desarrollador que tiene acceso de administrador a todos los sistemas.
Para corregir posibles oportunidades de acceso que hacen que los hackers tengan como destino el rol de desarrollador de software, tenga en cuenta los siguientes procedimientos recomendados de seguridad para aplicaciones de acceso con privilegios mínimos de confianza cero.
- Implemente el privilegio mínimo y el acceso cuando es necesario para DevOps. Asegúrese de que los miembros del equipo mantienen solo el acceso mínimo a los entornos durante el menor tiempo necesario. Coloque directivas para cubrir los derechos de acceso de administrador en los dispositivos principales, las herramientas de DevOps, las canalizaciones de versión, los repositorios de código, los entornos, los almacenes de secretos y las bases de datos. Para los equipos de DevOps, el requisito base es una conexión al almacén de identidades de la organización. Use la federación de identidades para la integración con entornos SaaS a fin de evitar el duplicado de identidades en plataformas de terceros y reducir el riesgo de exposición.
- No use tokens de acceso personal para el acceso al código fuente. Entre los procedimientos seguros para los equipos de DevOps se incluye el acceso a herramientas de DevOps basadas en SaaS y repositorios de código (mediante SSH, HTTPS o token de acceso personal). Para el acceso a entornos basados en SaaS, debe tener instrucciones claras sobre cómo los principios de acceso dictan quién puede descargar (clonar) los repositorios de código de los sistemas y desde qué dispositivos (locales, en la nube y en el contenedor). Por ejemplo, OneDrive puede bloquear o limitar el acceso a dispositivos no administrados.
- Estandarice y sincronice las cuentas de usuario de Usuario administrado por la empresa (EMU) de GitHub Enterprise con identidades corporativas. Con los usuarios administrados por la empresa, puede controlar las cuentas de usuario de los miembros de la empresa a través del proveedor de identidades (IdP). En el almacén de identidades de la organización, defina explícitamente nombres de usuario, correos electrónicos y nombres para mostrar de GitHub. A continuación, los usuarios identifican fácilmente a los colaboradores.
- En cuanto a las tres formas en que un desarrollador puede conectarse a un entorno de SaaS (HTTPS con una identidad, un token de acceso personal o conectarse con la clave SSH), conecte con el almacén de identidades de la organización. Con GitHub (excepto para las cuentas de EMU de GitHub), la identidad siempre es su identidad pública. El acceso controlado a través del inicio de sesión único (SSO) requiere conexión con el almacén de identidades de la organización.
- Use una autoridad de certificado (CA) SSH para proporcionar certificados SSH firmados de forma que los miembros accedan de forma segura a los recursos con Git. Un certificado SSH es un mecanismo para que una clave SSH firme otra clave SSH. GitHub Enterprise Cloud admite certificados SSH para proporcionar a las organizaciones más control sobre cómo acceden los miembros a los repositorios. Los administradores pueden cargar su clave pública de autoridad de certificado SSH y emitir certificados para que los miembros los usen para la autenticación de Git. Los certificados solo pueden acceder a repositorios que pertenezcan a la organización. Los administradores pueden requerir que los miembros usen certificados al acceder a sus repositorios.
- Use un administrador de credenciales de Git para proteger el acceso al código. Las herramientas como Visual Studio (VS) tienen compatibilidad integrada con las identidades. VS Code se aplaza a un Administrador de credenciales de Git.
Procedimientos recomendados para la seguridad de las ramas
Cuando los hackers obtienen acceso al repositorio de código, pueden estudiar la seguridad del sistema y modificar el código sin que los equipos se den cuenta. Para evitar el acceso no autorizado al repositorio de código, implemente una estrategia de ramas para establecer el control sobre los cambios de código (vea el ejemplo que se muestra en el diagrama siguiente).
Para corregir posibles oportunidades de acceso al repositorio, tenga en cuenta los siguientes procedimientos recomendados de seguridad de ramas.
- Proteja las ramas con revisiones de código para proporcionar a los equipos de DevOps control sobre los cambios de código y los avances de auditoría. La estrategia de ramas del diagrama anterior articula un flujo controlado de cambios que ofrece una cadena clara de comandos y planos técnicos para abordar los cambios en el código. De los distintos enfoques para la estrategia de ramas, algo que todos tienen en común es que las ramas protegidas actúan como origen de nuevas versiones en producción.
- Pida a los administradores de repositorios de Git que controlen las autorizaciones de aprobación. El mecanismo de control de las estrategias de ramas se basa en el flujo de trabajo de aprobación. Las ramas protegidas requieren validaciones, revisiones y aprobaciones para que se puedan aceptar cambios. Una opción es crear una regla de protección de rama para aplicar flujos de trabajo. Por ejemplo, requiera una revisión de aprobación o pasar comprobaciones de estado para todas las solicitudes de cambios combinadas en la rama protegida. Las directivas de rama ayudan a los equipos a proteger las ramas de desarrollo más importantes. Las directivas aplican los estándares de administración de cambios y la calidad del código del equipo.
Procedimientos recomendados para confiar en herramientas, extensiones e integraciones
La extensibilidad en entornos de desarrollo integrados (IDE) es tan productiva que básicamente es una característica obligatoria. Se basa en la capacidad de aplicar y conservar extensiones dentro del marketplace de un IDE específico para diseñar su entorno de trabajo óptimo.
Para corregir los IDE seguros, tenga en cuenta las siguientes herramientas, extensiones y procedimientos recomendados de integración.
- Asegúrese de integrar únicamente herramientas de marketplace y publicadores de confianza. Por ejemplo, el marketplace de VS Code tiene miles de extensiones que le facilitarán la vida. Sin embargo, cuando los equipos adoptan nuevas herramientas o extensiones, el aspecto más importante es probablemente la confiabilidad de un publicador.
- Configure prácticas seguras para controlar el uso de extensiones a fin de limitar la superficie expuesta a ataques de los entornos de desarrollo. La mayoría de las extensiones IDE requieren aprobar determinados privilegios para poder funcionar, a menudo suele ser un archivo con permisos de lectura en el sistema para analizar el código. Las extensiones requieren conexiones a entornos en la nube para poder funcionar (algo común en las herramientas de métricas). Aprobar funcionalidades adicionales además del IDE hace que las organizaciones se vean expuestas a más amenazas.
- En las máquinas de desarrollador, realice un seguimiento del número y el grado de desarrollo de las extensiones usadas para comprender la posible superficie expuesta a ataques. Incorpore solo extensiones del marketplace de VS Code de publicadores verificados. Al instalar extensiones de aplicación con VS Code, compruebe periódicamente las extensiones que está ejecutando con la línea de comandos, el código
--list-extensions --show-versions
. Conozca bien los componentes extensibles que está ejecutando en su entorno de desarrollo.
Pasos siguientes
- Seguridad de inserción de Confianza cero en el flujo de trabajo del desarrollador le ayuda a innovar de forma rápida y segura.
- Proteger el entorno de la plataforma DevOps le ayuda a implementar principios de confianza cero en el entorno de la plataforma DevOps y resalta los procedimientos recomendados para la administración de secretos y certificados.
- Entornos de DevOps seguros para Confianza cero describe los procedimientos recomendados para proteger los entornos de DevOps con un enfoque de confianza cero para evitar que los hackers ponga en peligro los cuadros de desarrollador, infecten canalizaciones de versión con scripts malintencionados y obtengan acceso a los datos de producción a través de entornos de prueba.
- Implemente los principios de confianza cero como se describe en el memorándum 22-09 (en apoyo de la orden ejecutiva de EE. UU. 14028, Mejora de la ciberseguridad de la nación) mediante el uso de Microsoft Entra ID como sistema centralizado de administración de identidades.
- Acelere y proteja el código con Azure DevOps con herramientas que proporcionan a los desarrolladores el código más rápido y seguro a la experiencia en la nube.
- Configure Azure para confiar en OIDC de GitHub como identidad federada. OpenID Connect (OIDC) permite a sus flujos de trabajo de Acciones de GitHub acceder a recursos de Azure sin tener que almacenar las credenciales de Azure como secretos de GitHub de larga duración.