![<\/a><\/div>\nSeg\u00fan una investigaci\u00f3n de GitGuardian y CyberArk, El 79 % de los responsables de la toma de decisiones de TI informaron haber experimentado una filtraci\u00f3n de secretos.<\/a>frente al 75% del informe del a\u00f1o anterior. Al mismo tiempo, el n\u00famero de credenciales filtradas nunca ha sido mayor, con m\u00e1s de 12,7 millones de credenciales codificadas s\u00f3lo en repositorios p\u00fablicos de GitHub<\/a>. Uno de los aspectos m\u00e1s preocupantes de este informe es que m\u00e1s del 90% de los secretos v\u00e1lidos encontrados y reportados permanecieron v\u00e1lidos durante m\u00e1s de cinco d\u00edas. <\/p>\nSeg\u00fan el mismo La investigaci\u00f3n, en promedio, lleva a las organizaciones 27 d\u00edas.<\/a> para remediar las credenciales filtradas. Combine eso con el hecho de que Las identidades no humanas superan en n\u00famero a las identidades humanas en al menos 45:1.<\/a>y es f\u00e1cil ver por qu\u00e9 muchas organizaciones se est\u00e1n dando cuenta de que detener la expansi\u00f3n de los secretos significa encontrar una manera de abordar esta crisis de identidad de las m\u00e1quinas. Desafortunadamente, la investigaci\u00f3n tambi\u00e9n muestra que muchos equipos est\u00e1n confundidos acerca de qui\u00e9n es el propietario de la seguridad de estas identidades. Es una tormenta perfecta de riesgo. <\/p>\n\u00bfPor qu\u00e9 la rotaci\u00f3n tarda tanto?<\/h2>\nEntonces, \u00bfpor qu\u00e9 tardamos tanto en rotar las credenciales si sabemos que son una de las rutas de ataque m\u00e1s f\u00e1ciles para los adversarios? Un factor importante que contribuye es la falta de claridad sobre c\u00f3mo se autorizan nuestras credenciales. Los permisos son los que autorizan qu\u00e9 cosas espec\u00edficas una entidad, como una carga de trabajo de Kubernetes o un microservicio, puede solicitar con \u00e9xito de otro servicio o fuente de datos. <\/p>\nRecordemos lo que significa remediar un incidente de expansi\u00f3n descontrolada de secretos: es necesario reemplazar de forma segura un secreto sin romper nada ni otorgar permisos nuevos y demasiado amplios, lo que potencialmente introducir\u00eda m\u00e1s riesgos de seguridad para su empresa. Si ya tiene una visi\u00f3n completa del ciclo de vida de sus identidades no humanas y sus secretos asociados, este es un proceso bastante sencillo para reemplazarlos con nuevos secretos con los mismos permisos. Esto puede llevar un tiempo considerable si a\u00fan no tiene esa informaci\u00f3n, ya que debe esperar que el desarrollador que lo cre\u00f3 originalmente todav\u00eda est\u00e9 all\u00ed y haya documentado lo que se hizo. <\/p>\nVeamos por qu\u00e9 la gesti\u00f3n de permisos es especialmente desafiante en entornos dominados por NHI, examinemos los desaf\u00edos que enfrentan los desarrolladores y los equipos de seguridad para equilibrar el control de acceso y la productividad, y analicemos c\u00f3mo un modelo de responsabilidad compartida podr\u00eda ayudar.<\/p>\n\u00bfA qui\u00e9n pertenece realmente la expansi\u00f3n de los secretos?<\/h2>\nLa expansi\u00f3n de secretos generalmente se refiere a la proliferaci\u00f3n de claves de acceso, contrase\u00f1as y otras credenciales confidenciales en entornos de desarrollo, repositorios y servicios como Slack o Jira. El \u00faltimo informe Voice of the Practitioners de GitGuardian destaca que el 65% de los encuestados atribuyen la responsabilidad de la remediaci\u00f3n directamente a los equipos de seguridad de TI. Al mismo tiempo, el 44 % de los l\u00edderes de TI informaron que los desarrolladores no siguen las mejores pr\u00e1cticas.<\/a> para la gesti\u00f3n de secretos. <\/p>\nLa expansi\u00f3n de los secretos y los problemas subyacentes de las credenciales de larga duraci\u00f3n con exceso de permisos seguir\u00e1n cayendo en esta brecha hasta que descubramos c\u00f3mo trabajar mejor juntos en un modelo de responsabilidad compartida<\/a>.<\/p>\nLa perspectiva del desarrollador sobre los permisos<\/h3>\nLos desarrolladores enfrentan una enorme presi\u00f3n para crear e implementar funciones r\u00e1pidamente. Sin embargo, administrar los permisos cuidadosamente, con las mejores pr\u00e1cticas de seguridad, puede resultar laborioso. Cada proyecto o aplicaci\u00f3n a menudo tiene sus propios requisitos de acceso \u00fanicos, que requieren tiempo para investigarse y configurarse adecuadamente, casi como si fuera un trabajo de tiempo completo adem\u00e1s del trabajo de creaci\u00f3n e implementaci\u00f3n de sus aplicaciones. Con demasiada frecuencia, las mejores pr\u00e1cticas para crear y administrar permisos no se aplican de manera uniforme en todos los equipos, rara vez se documentan adecuadamente o se olvidan por completo una vez que el desarrollador hace que la aplicaci\u00f3n funcione. <\/p>\nPara agravar el problema, en demasiados casos los desarrolladores simplemente otorgan permisos demasiado amplios a estas identidades de m\u00e1quinas. Un informe encontr\u00f3 que s\u00f3lo el 2% de los permisos concedidos se utilizan realmente.<\/a>. Si observamos m\u00e1s de cerca a qu\u00e9 se enfrentan, es f\u00e1cil ver por qu\u00e9.<\/p>\nPor ejemplo, piense en administrar permisos dentro de Amazon Web Services. Las pol\u00edticas de administraci\u00f3n de acceso e identidad (IAM) de AWS son conocidas por su flexibilidad, pero tambi\u00e9n son complejas y confusas de navegar. IAM admite varios tipos de pol\u00edticas (basadas en identidad, basadas en recursos y l\u00edmites de permisos), todas las cuales requieren configuraciones precisas. AWS tambi\u00e9n ofrece m\u00faltiples rutas de acceso para credenciales, incluidas funciones de IAM y concesiones de KMS (servicio de administraci\u00f3n de claves), cada una de las cuales viene con sus propias configuraciones de acceso \u00fanicas. Aprender este sistema no es tarea f\u00e1cil.<\/p>\nOtro ejemplo com\u00fan de un servicio donde los permisos pueden resultar dif\u00edciles de gestionar es GitHub. Las claves API pueden otorgar permisos a repositorios en varias organizaciones, lo que dificulta garantizar l\u00edmites de acceso adecuados. Una \u00fanica clave puede proporcionar involuntariamente un acceso excesivo entre entornos cuando los desarrolladores son miembros de varias organizaciones. Hay presi\u00f3n para hacerlo bien, mientras el tiempo siempre corre y el trabajo atrasado sigue aumentando. <\/p>\nPor qu\u00e9 los equipos de seguridad por s\u00ed solos no pueden solucionar este problema<\/h3>\nPuede parecer l\u00f3gico asignar a los equipos de seguridad la responsabilidad de monitorear y rotar los secretos; despu\u00e9s de todo, se trata de un problema de seguridad. La realidad es que estos equipos a menudo carecen del conocimiento granular a nivel de proyecto necesario para realizar cambios de forma segura. Los equipos de seguridad no siempre tienen el contexto para comprender qu\u00e9 permisos espec\u00edficos son esenciales para mantener las aplicaciones en ejecuci\u00f3n. Por ejemplo, un cambio de permiso aparentemente menor podr\u00eda interrumpir un proceso de CI\/CD, alterar la producci\u00f3n o incluso provocar una crisis en toda la empresa. falla en cascada si el servicio incorrecto desaparece<\/a>.<\/p>\nLa naturaleza dispersa de la gesti\u00f3n de secretos entre equipos y entornos tambi\u00e9n aumenta la superficie de ataque. Sin nadie realmente a cargo, resulta mucho m\u00e1s dif\u00edcil mantener la coherencia en los controles de acceso y las pistas de auditor\u00eda. Esta fragmentaci\u00f3n a menudo da como resultado que las credenciales excesivas u obsoletas y sus permisos asociados permanezcan activos durante demasiado tiempo, posiblemente para siempre. Puede dificultar saber qui\u00e9n tiene acceso leg\u00edtimo o ileg\u00edtimo a qu\u00e9 secretos en un momento dado.<\/p>\nUn modelo de responsabilidad compartida para una rotaci\u00f3n m\u00e1s r\u00e1pida<\/h2>\nLos desarrolladores y los equipos de seguridad podr\u00edan ayudar a abordar estos problemas reuni\u00e9ndose en el medio y construyendo un modelo de responsabilidad compartida. En tal modelo, los desarrolladores son m\u00e1s responsables de administrar consistentemente sus permisos a trav\u00e9s de herramientas adecuadas, como Administrador de secretos de Conjur de CyberArk<\/a> o B\u00f3veda de HashiCorp<\/a>al mismo tiempo que documenta mejor los permisos y el alcance de los permisos necesarios a nivel de proyecto. Los equipos de seguridad deber\u00edan ayudar a los desarrolladores trabajando para automatizar la rotaci\u00f3n de secretos, invirtiendo en herramientas de observabilidad adecuadas para obtener claridad sobre el estado de los secretos y trabajando con TI para eliminar por completo las credenciales de larga duraci\u00f3n. <\/p>\nSi los desarrolladores documentan claramente qu\u00e9 permisos son necesarios en sus requisitos, podr\u00eda ayudar a los equipos de seguridad a realizar auditor\u00edas m\u00e1s r\u00e1pidas y precisas y acelerar la remediaci\u00f3n. Si los equipos de seguridad trabajan para garantizar que el camino general m\u00e1s f\u00e1cil y r\u00e1pido hacia la implementaci\u00f3n de un nuevo secreto de identidad no humana sea tambi\u00e9n el m\u00e1s seguro y escalable, entonces habr\u00e1 muchos menos incidentes que requieran una rotaci\u00f3n de emergencia y todos ganar\u00e1n. <\/p>\nEl objetivo de los desarrolladores debe ser garantizar que el equipo de seguridad pueda rotar o actualizar las credenciales en sus aplicaciones con confianza, por s\u00ed solos, sabiendo que no est\u00e1n poniendo en peligro la producci\u00f3n.<\/p>\nPreguntas clave a abordar sobre permisos<\/h3>\nAl pensar en lo que se debe documentar, aqu\u00ed hay algunos puntos de datos espec\u00edficos para ayudar a que este esfuerzo entre equipos fluya mejor: <\/p>\n\n\u00bfQui\u00e9n cre\u00f3 la credencial?<\/b> – A muchas organizaciones les resulta dif\u00edcil realizar un seguimiento de la propiedad de las credenciales, especialmente cuando una clave se comparte o rota. Este conocimiento es esencial para comprender qui\u00e9n es responsable de rotar o revocar las credenciales.<\/li>\n\u00bfA qu\u00e9 recursos accede?<\/b> – Las claves API a menudo pueden acceder a una variedad de servicios, desde bases de datos hasta integraciones de terceros, por lo que es esencial limitar los permisos al m\u00ednimo necesario.<\/li>\n\u00bfQu\u00e9 permisos otorga? <\/b>– Los permisos var\u00edan ampliamente seg\u00fan los roles, las pol\u00edticas basadas en recursos y las condiciones de las pol\u00edticas. Por ejemplo, en Jenkins, un usuario con permiso “General\/Lectura” puede ver informaci\u00f3n general, mientras que “General\/Administrar” otorga control total sobre el sistema.<\/li>\n\u00bfC\u00f3mo lo revocamos o rotamos?<\/b> – La facilidad de revocaci\u00f3n var\u00eda seg\u00fan la plataforma y, en muchos casos, los equipos deben rastrear manualmente las claves y los permisos en todos los sistemas, lo que complica la remediaci\u00f3n y prolonga la exposici\u00f3n a las amenazas.<\/li>\n\u00bfEst\u00e1 activa la credencial?<\/b> – Es fundamental saber si una credencial todav\u00eda est\u00e1 en uso. Cuando los NHI utilizan claves API de larga duraci\u00f3n, estas credenciales pueden permanecer activas indefinidamente a menos que se administren adecuadamente, lo que crea riesgos de acceso persistentes.<\/li>\n<\/ol>\nLos permisos son desafiantes, pero podemos administrarlos juntos como un solo equipo<\/h2>\nSeg\u00fan el informe de GitGuardian, si bien el 75% de los encuestados expresaron confianza en sus capacidades de gesti\u00f3n de secretos, la realidad suele ser muy diferente. El tiempo promedio de remediaci\u00f3n de 27 d\u00edas refleja esta brecha entre confianza y pr\u00e1ctica. Es hora de repensar c\u00f3mo implementamos y comunicamos secretos y sus permisos como organizaci\u00f3n.<\/p>\nSi bien los desarrolladores trabajan diligentemente para equilibrar la seguridad y la funcionalidad, la falta de procesos de permisos optimizados y rutas de documentaci\u00f3n no centralizadas o no estandarizadas solo amplifican los riesgos. Los equipos de seguridad por s\u00ed solos no pueden resolver estos problemas de forma eficaz debido a su conocimiento limitado de las necesidades espec\u00edficas del proyecto. Necesitan trabajar mano a mano con los desarrolladores en cada paso del camino. <\/p>\nGitGuardian est\u00e1 creando la pr\u00f3xima generaci\u00f3n de herramientas de seguridad de secretos, ayudando a los equipos de seguridad y de TI a controlar la expansi\u00f3n de los secretos. Saber qu\u00e9 credenciales de texto sin formato y de larga duraci\u00f3n est\u00e1n expuestas en su c\u00f3digo y en otros entornos es un primer paso necesario para eliminar esta amenaza. Comience hoy con GitGuardian<\/a>.<\/em><\/p>\n<\/p>\n\u00bfEncontr\u00f3 interesante este art\u00edculo? Este art\u00edculo es una contribuci\u00f3n de uno de nuestros valiosos socios.<\/span> S\u00edguenos en Gorjeo \uf099<\/i><\/a> y LinkedIn<\/a> para leer m\u00e1s contenido exclusivo que publicamos.<\/div>\n<\/div>\n](\"https:\/\/teknomers.com\/es\/wp-content\/uploads\/2024\/11\/El-problema-de-los-permisos-y-las-identidades-no-humanas.png\"){kind=link}
Seg\u00fan una investigaci\u00f3n de GitGuardian y CyberArk, El 79 % de los responsables de la toma de decisiones de TI informaron haber experimentado una filtraci\u00f3n de secretos.<\/a>frente al 75% del informe del a\u00f1o anterior. Al mismo tiempo, el n\u00famero de credenciales filtradas nunca ha sido mayor, con m\u00e1s de 12,7 millones de credenciales codificadas s\u00f3lo en repositorios p\u00fablicos de GitHub<\/a>. Uno de los aspectos m\u00e1s preocupantes de este informe es que m\u00e1s del 90% de los secretos v\u00e1lidos encontrados y reportados permanecieron v\u00e1lidos durante m\u00e1s de cinco d\u00edas. <\/p>\n Seg\u00fan el mismo La investigaci\u00f3n, en promedio, lleva a las organizaciones 27 d\u00edas.<\/a> para remediar las credenciales filtradas. Combine eso con el hecho de que Las identidades no humanas superan en n\u00famero a las identidades humanas en al menos 45:1.<\/a>y es f\u00e1cil ver por qu\u00e9 muchas organizaciones se est\u00e1n dando cuenta de que detener la expansi\u00f3n de los secretos significa encontrar una manera de abordar esta crisis de identidad de las m\u00e1quinas. Desafortunadamente, la investigaci\u00f3n tambi\u00e9n muestra que muchos equipos est\u00e1n confundidos acerca de qui\u00e9n es el propietario de la seguridad de estas identidades. Es una tormenta perfecta de riesgo. <\/p>\n Entonces, \u00bfpor qu\u00e9 tardamos tanto en rotar las credenciales si sabemos que son una de las rutas de ataque m\u00e1s f\u00e1ciles para los adversarios? Un factor importante que contribuye es la falta de claridad sobre c\u00f3mo se autorizan nuestras credenciales. Los permisos son los que autorizan qu\u00e9 cosas espec\u00edficas una entidad, como una carga de trabajo de Kubernetes o un microservicio, puede solicitar con \u00e9xito de otro servicio o fuente de datos. <\/p>\n Recordemos lo que significa remediar un incidente de expansi\u00f3n descontrolada de secretos: es necesario reemplazar de forma segura un secreto sin romper nada ni otorgar permisos nuevos y demasiado amplios, lo que potencialmente introducir\u00eda m\u00e1s riesgos de seguridad para su empresa. Si ya tiene una visi\u00f3n completa del ciclo de vida de sus identidades no humanas y sus secretos asociados, este es un proceso bastante sencillo para reemplazarlos con nuevos secretos con los mismos permisos. Esto puede llevar un tiempo considerable si a\u00fan no tiene esa informaci\u00f3n, ya que debe esperar que el desarrollador que lo cre\u00f3 originalmente todav\u00eda est\u00e9 all\u00ed y haya documentado lo que se hizo. <\/p>\n Veamos por qu\u00e9 la gesti\u00f3n de permisos es especialmente desafiante en entornos dominados por NHI, examinemos los desaf\u00edos que enfrentan los desarrolladores y los equipos de seguridad para equilibrar el control de acceso y la productividad, y analicemos c\u00f3mo un modelo de responsabilidad compartida podr\u00eda ayudar.<\/p>\n La expansi\u00f3n de secretos generalmente se refiere a la proliferaci\u00f3n de claves de acceso, contrase\u00f1as y otras credenciales confidenciales en entornos de desarrollo, repositorios y servicios como Slack o Jira. El \u00faltimo informe Voice of the Practitioners de GitGuardian destaca que el 65% de los encuestados atribuyen la responsabilidad de la remediaci\u00f3n directamente a los equipos de seguridad de TI. Al mismo tiempo, el 44 % de los l\u00edderes de TI informaron que los desarrolladores no siguen las mejores pr\u00e1cticas.<\/a> para la gesti\u00f3n de secretos. <\/p>\n La expansi\u00f3n de los secretos y los problemas subyacentes de las credenciales de larga duraci\u00f3n con exceso de permisos seguir\u00e1n cayendo en esta brecha hasta que descubramos c\u00f3mo trabajar mejor juntos en un modelo de responsabilidad compartida<\/a>.<\/p>\n Los desarrolladores enfrentan una enorme presi\u00f3n para crear e implementar funciones r\u00e1pidamente. Sin embargo, administrar los permisos cuidadosamente, con las mejores pr\u00e1cticas de seguridad, puede resultar laborioso. Cada proyecto o aplicaci\u00f3n a menudo tiene sus propios requisitos de acceso \u00fanicos, que requieren tiempo para investigarse y configurarse adecuadamente, casi como si fuera un trabajo de tiempo completo adem\u00e1s del trabajo de creaci\u00f3n e implementaci\u00f3n de sus aplicaciones. Con demasiada frecuencia, las mejores pr\u00e1cticas para crear y administrar permisos no se aplican de manera uniforme en todos los equipos, rara vez se documentan adecuadamente o se olvidan por completo una vez que el desarrollador hace que la aplicaci\u00f3n funcione. <\/p>\n Para agravar el problema, en demasiados casos los desarrolladores simplemente otorgan permisos demasiado amplios a estas identidades de m\u00e1quinas. Un informe encontr\u00f3 que s\u00f3lo el 2% de los permisos concedidos se utilizan realmente.<\/a>. Si observamos m\u00e1s de cerca a qu\u00e9 se enfrentan, es f\u00e1cil ver por qu\u00e9.<\/p>\n Por ejemplo, piense en administrar permisos dentro de Amazon Web Services. Las pol\u00edticas de administraci\u00f3n de acceso e identidad (IAM) de AWS son conocidas por su flexibilidad, pero tambi\u00e9n son complejas y confusas de navegar. IAM admite varios tipos de pol\u00edticas (basadas en identidad, basadas en recursos y l\u00edmites de permisos), todas las cuales requieren configuraciones precisas. AWS tambi\u00e9n ofrece m\u00faltiples rutas de acceso para credenciales, incluidas funciones de IAM y concesiones de KMS (servicio de administraci\u00f3n de claves), cada una de las cuales viene con sus propias configuraciones de acceso \u00fanicas. Aprender este sistema no es tarea f\u00e1cil.<\/p>\n Otro ejemplo com\u00fan de un servicio donde los permisos pueden resultar dif\u00edciles de gestionar es GitHub. Las claves API pueden otorgar permisos a repositorios en varias organizaciones, lo que dificulta garantizar l\u00edmites de acceso adecuados. Una \u00fanica clave puede proporcionar involuntariamente un acceso excesivo entre entornos cuando los desarrolladores son miembros de varias organizaciones. Hay presi\u00f3n para hacerlo bien, mientras el tiempo siempre corre y el trabajo atrasado sigue aumentando. <\/p>\n Puede parecer l\u00f3gico asignar a los equipos de seguridad la responsabilidad de monitorear y rotar los secretos; despu\u00e9s de todo, se trata de un problema de seguridad. La realidad es que estos equipos a menudo carecen del conocimiento granular a nivel de proyecto necesario para realizar cambios de forma segura. Los equipos de seguridad no siempre tienen el contexto para comprender qu\u00e9 permisos espec\u00edficos son esenciales para mantener las aplicaciones en ejecuci\u00f3n. Por ejemplo, un cambio de permiso aparentemente menor podr\u00eda interrumpir un proceso de CI\/CD, alterar la producci\u00f3n o incluso provocar una crisis en toda la empresa. falla en cascada si el servicio incorrecto desaparece<\/a>.<\/p>\n La naturaleza dispersa de la gesti\u00f3n de secretos entre equipos y entornos tambi\u00e9n aumenta la superficie de ataque. Sin nadie realmente a cargo, resulta mucho m\u00e1s dif\u00edcil mantener la coherencia en los controles de acceso y las pistas de auditor\u00eda. Esta fragmentaci\u00f3n a menudo da como resultado que las credenciales excesivas u obsoletas y sus permisos asociados permanezcan activos durante demasiado tiempo, posiblemente para siempre. Puede dificultar saber qui\u00e9n tiene acceso leg\u00edtimo o ileg\u00edtimo a qu\u00e9 secretos en un momento dado.<\/p>\n Los desarrolladores y los equipos de seguridad podr\u00edan ayudar a abordar estos problemas reuni\u00e9ndose en el medio y construyendo un modelo de responsabilidad compartida. En tal modelo, los desarrolladores son m\u00e1s responsables de administrar consistentemente sus permisos a trav\u00e9s de herramientas adecuadas, como Administrador de secretos de Conjur de CyberArk<\/a> o B\u00f3veda de HashiCorp<\/a>al mismo tiempo que documenta mejor los permisos y el alcance de los permisos necesarios a nivel de proyecto. Los equipos de seguridad deber\u00edan ayudar a los desarrolladores trabajando para automatizar la rotaci\u00f3n de secretos, invirtiendo en herramientas de observabilidad adecuadas para obtener claridad sobre el estado de los secretos y trabajando con TI para eliminar por completo las credenciales de larga duraci\u00f3n. <\/p>\n Si los desarrolladores documentan claramente qu\u00e9 permisos son necesarios en sus requisitos, podr\u00eda ayudar a los equipos de seguridad a realizar auditor\u00edas m\u00e1s r\u00e1pidas y precisas y acelerar la remediaci\u00f3n. Si los equipos de seguridad trabajan para garantizar que el camino general m\u00e1s f\u00e1cil y r\u00e1pido hacia la implementaci\u00f3n de un nuevo secreto de identidad no humana sea tambi\u00e9n el m\u00e1s seguro y escalable, entonces habr\u00e1 muchos menos incidentes que requieran una rotaci\u00f3n de emergencia y todos ganar\u00e1n. <\/p>\n El objetivo de los desarrolladores debe ser garantizar que el equipo de seguridad pueda rotar o actualizar las credenciales en sus aplicaciones con confianza, por s\u00ed solos, sabiendo que no est\u00e1n poniendo en peligro la producci\u00f3n.<\/p>\n Al pensar en lo que se debe documentar, aqu\u00ed hay algunos puntos de datos espec\u00edficos para ayudar a que este esfuerzo entre equipos fluya mejor: <\/p>\n Seg\u00fan el informe de GitGuardian, si bien el 75% de los encuestados expresaron confianza en sus capacidades de gesti\u00f3n de secretos, la realidad suele ser muy diferente. El tiempo promedio de remediaci\u00f3n de 27 d\u00edas refleja esta brecha entre confianza y pr\u00e1ctica. Es hora de repensar c\u00f3mo implementamos y comunicamos secretos y sus permisos como organizaci\u00f3n.<\/p>\n Si bien los desarrolladores trabajan diligentemente para equilibrar la seguridad y la funcionalidad, la falta de procesos de permisos optimizados y rutas de documentaci\u00f3n no centralizadas o no estandarizadas solo amplifican los riesgos. Los equipos de seguridad por s\u00ed solos no pueden resolver estos problemas de forma eficaz debido a su conocimiento limitado de las necesidades espec\u00edficas del proyecto. Necesitan trabajar mano a mano con los desarrolladores en cada paso del camino. <\/p>\n GitGuardian est\u00e1 creando la pr\u00f3xima generaci\u00f3n de herramientas de seguridad de secretos, ayudando a los equipos de seguridad y de TI a controlar la expansi\u00f3n de los secretos. Saber qu\u00e9 credenciales de texto sin formato y de larga duraci\u00f3n est\u00e1n expuestas en su c\u00f3digo y en otros entornos es un primer paso necesario para eliminar esta amenaza. Comience hoy con GitGuardian<\/a>.<\/em><\/p>\n <\/p>\n\u00bfPor qu\u00e9 la rotaci\u00f3n tarda tanto?<\/h2>\n
\u00bfA qui\u00e9n pertenece realmente la expansi\u00f3n de los secretos?<\/h2>\n
La perspectiva del desarrollador sobre los permisos<\/h3>\n
Por qu\u00e9 los equipos de seguridad por s\u00ed solos no pueden solucionar este problema<\/h3>\n
Un modelo de responsabilidad compartida para una rotaci\u00f3n m\u00e1s r\u00e1pida<\/h2>\n
Preguntas clave a abordar sobre permisos<\/h3>\n
\n
Los permisos son desafiantes, pero podemos administrarlos juntos como un solo equipo<\/h2>\n