¿Cómo puedo desalentar el intercambio de claves API internas dentro de una empresa?

37

Estamos trabajando en un nuevo servicio: este servicio se llamará directamente desde las aplicaciones en los dispositivos de los usuarios. Estas aplicaciones serán desarrolladas y respaldadas por múltiples equipos de desarrollo de toda la organización, todo dependiendo de los datos que proporcionemos.

Estamos interesados en identificar qué aplicaciones envían qué solicitudes, para poder identificar patrones de uso y desarrolladores responsables. (Para evitar dudas, la autenticación del usuario se maneja por separado).

Nuestra solución es requerir claves API, una por aplicación, luego tenemos los datos de contacto del equipo de desarrollo.

No queremos que las claves API sean una fuente de fricción, pero nos preocupa que los desarrolladores las compartan con colegas de otros equipos, lo que significa que ya no podemos identificar el tráfico para una sola aplicación.

¿Cómo podemos incentivar a los desarrolladores para que no compartan las claves API internamente?

api enterprise-development

— Oli
fuente

55

¿Cómo accederán estos equipos a la API? ¿A través de la red interna? En general, se colocan diferentes equipos en diferentes subredes para que pueda imponer el uso de una determinada clave API por red ... De todos modos, la solución social es decirles "es importante que no compartan esta clave API no por seguridad sino porque necesitan las métricas de diferentes usuarios para mejorarlo. Si alguien le pregunta, simplemente dígale que nos lo pida y con gusto y eficientemente le proporcionaremos una clave API ".

— Giacomo Alzetta

3

Si no desea que las personas compartan las claves con sus colegas, facilite la inclusión de un archivo de configuración que el sistema de versiones ignora (para que la clave nunca se confirme) y también facilite la creación de nuevas claves. Nadie se molestará en compartir una clave secreta si otro desarrollador puede crear fácilmente una nueva clave por sí mismo. El problema de compartir claves personales suele ser un problema causado por el hecho de que obtener nuevas claves lleva tiempo.

— Sulthan

¿Ha considerado solicitar el registro cuando se inicia la aplicación por primera vez? Podría mostrar una pantalla de inicio solicitando los datos de contacto del usuario (o cualquier información que necesite) y luego emitir la clave API en el acto.

— John Wu

"¿Cómo podemos incentivar a los desarrolladores para que no compartan las claves API internamente?" En pocas palabras, vincule cada clave a la dirección MAC de las tarjetas de red en las computadoras que las ejecutan. Los protocolos de red evitan que se usen las mismas direcciones MAC en la misma red, por lo que evita que las personas usen las mismas claves una y otra vez. Hubiera convertido esto en una respuesta, pero no tengo el representante para ello actualmente.

— Blerg

Curiosamente, no veo la palabra "rotación" (como en la rotación de teclas - expiración / rotación de credenciales) en ninguna parte de esta página en este momento. Una vez que alguien obtiene una clave, ¿tiene una vida útil finita después de la cual debe rotarse fuera de uso y reemplazarse por una nueva? ¿Si no, porque no?

— Michael - sqlbot

76

Para compartir esas claves entre los equipos, los equipos deben hablar entre ellos, acordar compartir y luego compartirlas. Esto lleva tiempo. Por lo tanto, si un equipo puede solicitarle claves API de manera más rápida y sencilla, no hay incentivos para compartir.

Y la forma más fácil para que soliciten esas claves es que las evite. Suponiendo que conoce a todos los otros equipos que necesitarán claves API, créelos y compártalos antes de poner el servicio a su disposición.

Hay otro incentivo que puede ofrecer: soporte de depuración. Esos equipos querrán su ayuda cuando las cosas no funcionen correctamente cuando integren su trabajo con su servicio. Esas claves API le permiten rastrear sus solicitudes específicas y, por lo tanto, ayudar a depurar lo que está mal. Así que venda eso como la razón de las claves, en lugar de " identificar patrones de uso y desarrolladores responsables ", lo que parece que está espiando sus actividades.

— David Arno
fuente

2

Re: compartir, en un mundo ideal tienes razón, pero estás presuponiendo que tienen información perfecta (aunque puedo ayudarte dirigiéndolos a documentos desde el esquema, la raíz del punto final y cualquier error) y la gestión cooperativa, y no es la realidad donde todo lo que pueden tener es el punto final y un código copiado de otro equipo que fueron enviados por un gerente superior.

— Oli

3

Re: preventivo, tienes toda la razón, debemos crear agresivamente y enviar claves a las partes interesadas. Lo que no mencioné es que algunas de estas aplicaciones usan un marco / interfaz común, y quizás podríamos inyectar o aplicar semiautomáticamente claves únicas en esa capa, pero eso no se aplica a todas las aplicaciones.

— Oli

1

@Ewan si simplemente deshabilita el acceso a la clave dada, todos los usuarios correrán hacia usted, sin necesidad de perseguirlos. Y luego puedes darles llaves únicas :)

— Alexei Levenkov

15

La opción preventiva debe tomar esta forma: acceder a la API sin la clave produce un mensaje de error con un enlace a la página donde solicita la clave. No esperes que nadie lea la documentación. Los incentivos no funcionan cuando nadie los conoce.

— candied_orange

1

Si los mensajes de error o los registros de depuración se envían automáticamente por correo electrónico a una dirección vinculada a la clave, cualquiera que desee los datos tendrá un incentivo para usar su propia clave, y cualquiera que haya compartido la clave tendrá un incentivo para localizar a la persona que la compartió. y hacer que se detengan.

— Robin Bennett

20

Buenas respuestas ya, solo pensé en un enfoque diferente que puede o no funcionar para usted.

En lugar de emitir claves para que se incluyan, puede requerir que el encabezado de las solicitudes incluya el nombre de la aplicación front-end, para que sea creado y formateado por el desarrollador de la aplicación front-end, como lo hacen los navegadores web. De esa manera, los front-end aún podrían pretender ser una aplicación diferente, pero no sería beneficioso hacerlo, por lo que parece poco probable. Simplemente deje que el front-end se identifique y acepte cualquier cadena no vacía.

— Martin Maat
fuente

Eso haría la vida un poco más difícil si la propiedad de una aplicación cambiara; por ejemplo, podríamos actualizar los detalles de la clave API almacenados en nuestro extremo, pero si aceptamos texto de forma libre que requiere que la aplicación realice un cambio de código.

— Oli

1

@Oli Si la propiedad de una aplicación cambiara y el (nuevo) desarrollador considerara apropiado actualizar la identidad de la aplicación (que realmente tiene porque alguien más la está manteniendo), ¿cuál sería el problema? Puede diferenciar entre el cambio previo a la propiedad y el cambio posterior a la propiedad, solo considérelos como dos aplicaciones diferentes. Sin embargo, no esperaría que ningún nuevo propietario note el nombre en el encabezado pronto.

— Martin Maat

3

Esto es lo que hago. haga que el cliente tenga un parámetro de construcción que es el nombre de la aplicación y / o use la reflexión para extraer otras cosas como la máquina en la que se está ejecutando, su versión, etc. La clave es permitirle informar cuando las personas NO siguen su API política

— Ewan

1

Si la organización tiene un enfoque común para el control de versiones, por ejemplo, todos guardan su código en el servidor GitHub de la organización, haga que cada aplicación envíe una URL a su repositorio y el hash de confirmación desde el que se creó. El hash de confirmación se puede incluir en el código como parte del proceso de compilación, por lo que no es necesario que los desarrolladores actualicen nada. Tener la URL de repositorio le permite ver quién es el propietario, y obtener confirmaciones específicas le permitiría notar diferencias de comportamiento entre las versiones.

— Caleb

@Caleb Si las cosas se centralizaran así, el OP probablemente no tendría este problema. Por lo que entiendo, los desarrolladores de aplicaciones front-end son mucho anónimos para el OP, con formas privadas de desarrollo de software.

— Martin Maat

16

En breve:

Primero: facilitación y beneficios; Si es necesario: fricción y policía.

Algunas palabras mas

Facilitación : Primero, facilite que un equipo obtenga una nueva clave API. Por ejemplo, agregue un recordatorio en los procedimientos corporativos para lanzar nuevos proyectos y ofrezca un servicio fácil de usar para solicitar nuevas claves, sin pedir justificación.

Beneficios : hacer que el uso de una clave API propia sea un beneficio para el equipo o el propietario del producto. Por ejemplo, proponga algunos comentarios sobre el uso de la aplicación en función de esa clave.

Fricción : Dependiendo de la función clave, puede crear fricción, por ejemplo, si la clave está vinculada a un dominio definido por la aplicación somme (es decir, reutilizar las claves no necesariamente daría acceso a todos los servicios deseados).

Vigilancia : Finalmente, es posible que deba prever algunas medidas de vigilancia. Por ejemplo, puede monitorear el uso de las funciones de la API mediante la clave de la API y después de un tiempo determinado para establecer una línea de base, preguntar sobre el uso de las partes de la API que no se espera en vista de la línea de base. O si esto no es realista, simplemente incluya en las listas de verificación de revisión del proyecto corporativo la verificación de que se utilizó una clave válida.

Observación : es posible que deba ser muy claro en su política de clave API: ¿una nueva versión principal requeriría su propia clave API? ¿Qué pasa con un tenedor, o si una aplicación está dividida? ¿Qué pasa si otro equipo está a cargo, etc.?

— Christophe
fuente

6

En general, la forma más fácil de lograr que los desarrolladores "hagan lo correcto" es facilitarles que lo hagan.

Para ello, sugeriría crear una página / sitio web de emisión de claves API. En su forma más simple, podría ser solo un inicio de sesión (idealmente vinculado a su AD / LDAP corporativo) y la página que solo solicita el nombre de la aplicación y emite la clave.

Al final del día, siempre puede revocar las claves más adelante, por lo que todo lo que realmente necesita que haga el sitio es registrar quién (nombre de usuario) solicitó la clave y qué (nombre de la aplicación) quieren hacer con ella, junto con cualquier información necesaria para revocar la clave más tarde.

Podría hacer algo similar con un sistema de tickets, pero al final del día es muy fácil para mí copiar y pegar una clave de una aplicación a otra, por lo que debe ser realmente fácil solicitar una nueva clave, para evitar errores comportamiento.

— DavidT
fuente

1

Ser proactivo.

Identifique posibles desarrolladores y DÉLE claves de API únicas en un canal seguro, con anticipación. Proporcione un medio fácil para solicitar nuevas claves API. Proporcione un medio fácil para que nuevas personas soliciten nuevas claves API. Cuando nuevos pasantes o empleados se unan al equipo, entrégueles un boleto JIRA o similar "Solicite una clave API" con los pasos en la descripción.

Mantenga un registro de qué claves API se han utilizado y cuáles no. Si Bob ha enviado tickets en el proyecto pero no ha estado usando sus claves API, entonces probablemente haya tomado prestado el de otra persona.

Tener el apoyo de la gerencia. No seas una entrometida Nancy haciendo reglas de maquillaje que no importan. Literalmente convencer a la Administración de que es importante, y luego ellos son los que convencerán al grupo de que es importante. No trabajes para convencer a todos.

Y la sugerencia más molesta y propensa a la tiranía: ser consciente del mal uso y tomar medidas enérgicas el mismo día. La misma hora es la mejor. No diga "Desarrollador malo malo", diga "Aquí están los pasos correctos". Si lo hacen repetidamente, deshabilite la clave mal utilizada. Esto molesta tanto al que comparte como al que pidió prestado, y el que comparte dirá "No, hazlo correctamente" en el futuro. Evite deshabilitar claves que se encuentran en proyectos en vivo.

— Christopher Hostage
fuente

1

¿Cómo podemos incentivar a los desarrolladores para que no compartan las claves API internamente?

Genere claves como resultado del registro de la aplicación de autoservicio .
Requerir un punto de contacto antes de que las teclas se activen.
Y pídales que no compartan. (Cree un término de servicio y / o dígales por qué es mejor que no lo compartan).

También debe implementar la limitación de velocidad . Esto en sí mismo podría desalentar el intercambio de claves. Protege su sistema hasta cierto punto contra aplicaciones abusivas. (Y francamente maliciosos). Y asegura que estará algo informado antes de un aumento masivo en el tráfico útil. (¡Espero darle tiempo para agregar capacidad!)

Y, con limitación de velocidad, cuando una aplicación requiere un límite superior, abre un diálogo con el POC registrado para la clave. Tiene la oportunidad de preguntar si se comparten las claves, explicar por qué es perjudicial, etc., y puede ofrecer claves adicionales cuando sea apropiado en lugar de los cambios de límite de tarifa solicitados. Etc.

— svidgen
fuente

0

Una forma de hacer las cosas, especialmente si los equipos usan un sistema de compilación compartido (o al menos uno lo suficientemente común) es configurar un servidor interno que cree y emita claves API (dados algunos bits básicos de información sobre el producto que lo usa ) Luego use un script que tome una nueva clave API del servidor para cada compilación o para cada actualización de versión. Deje que los desarrolladores ejecuten el script para obtener una clave diferente para sus compilaciones locales también. (Donde sea posible, automatice esto como parte de la compilación para que ni siquiera tengan que pensarlo).

Esto le permitiría saber si se trataba de algo en producción, control de calidad o desarrollo, y en qué versión / compilación comenzaron los problemas.

— Miral
fuente

0

Lo primero y lo mejor que puede hacer es formatear las claves para que incluyan el nombre de la aplicación en un formato fácil de leer, y no funcionen si lo cambia.

Si es obvio cuando los equipos están usando la clave incorrecta, se esforzarán por no hacerlo.

Luego, expire periódicamente las claves. Debe hacer esto de todos modos , y cuando una clave esté a punto de caducar, puede enviar una nueva al equipo que la posee. El equipo que usa una clave estará motivado para asegurarse de que es el equipo que la posee, de modo que obtenga la nueva cuando caduque.

— Matt Timmermans
fuente

1

en la práctica, aunque expirar las claves puede ser un gran obstáculo para la adopción de la aplicación, puedo ver a los gerentes decir "fuggetaboutit", ya que será un problema más adelante.

— davidbak