Así que me uní a un nuevo equipo que desarrolla y opera un servicio disponible en Internet. Está dirigido al uso B2B más que al consumidor, aunque cualquiera puede registrarse para obtener una cuenta de bajo nivel para comprobarlo (¡no llegarás a ninguna parte si los desarrolladores de tus clientes potenciales no pueden jugar antes de que los trajes firmen un acuerdo! ).
Recientemente, para mi sorpresa, descubrí que algunas cosas que esperaría que se entregaran a través de HTTPS a un conjunto de certificados de cliente estrictamente controlado se transmiten a través de HTTP abierto sin autenticación de ningún tipo. Cosas como un almacén de claves/valores de Consul, en el que algunos de los valores son contraseñas, o un registro privado de Docker en el que algunas de las imágenes contienen claves privadas (hay un proyecto en marcha para eliminar claves de las imágenes e inyectarlas en tiempo de ejecución, pero las imágenes antiguas todavía están en el registro y no me gustaría apostar a que se hayan cambiado las claves). Probablemente hay otros servicios en una situación similar que aún no he encontrado.
El colega al que le pregunté sobre esto estuvo de acuerdo en que no era lo ideal, pero no le preocupaba porque estos servicios sólo están expuestos en la red privada dentro del centro de datos (alojado por un tercero). No se pueden enrutar (si todo funciona correctamente) desde Internet, gracias a Dios. Sin embargo, parece mucha confianza para poner en la configuración de enrutamiento de la red, sin mencionar que si uno de los servidores se ve comprometido, su acceso a la red interna significa que el resto son blancos fáciles.
Este es mi primer trabajo dirigiendo un servicio público, hasta ahora he trabajado en el mundo "shrinkwrap" donde vendemos software pero nuestros clientes lo instalan y ejecutan. Así que no tengo idea de lo malo que es esto. Voy a plantearlo e intentar arreglarlo, pero quería que una comunidad con más experiencia en la ejecución de servicios de producción lo ejecutara para calibrar qué tan fuerte debería gritar. ¿Es esto realmente terrible y deberíamos dejar todo hasta que se solucione, o no es bueno pero en realidad no es tan infrecuente?
Publicando como invitado ya que no quiero dar ninguna pista sobre de quién es este servicio :)
Respuesta1
No creo que esto sea un gran problema, con unoadvertencia:proporcionó la red que conecta los servidores privados(ya sea virtual o físico)esta conmutado, esto no es un gran problema.
Mi mantra habitual es que no existe la seguridad.en el resumen, sólo amenazas y respuestas a las mismas, apropiadas o no. Entonces, ¿cuál es su modelo de amenaza? Un atacante compromete el servidor conectado a Internet; ¿Qué puede hacer ahora?
SSL (incluido HTTPS) en la red proporciona dos servicios: cifrado y autenticación. El cifrado no proporciona ninguna protección contra este modelo de amenaza: siempre que la red de back-end esté conmutada, el atacante sólo puede ver el tráfico hacia y desde el servidor comprometido. Como se trata de un punto final SSL, él podría leer todo ese tráfico.de todos modos. La autenticación proporciona un ligero beneficio, pero es sólo un rastro: incluso si no usaron los certificados autofirmados habituales (que tienden a destruir la autenticación), puedes estar bastante seguro de que realmente estás hablando con los servidores back-end, porque usted controla la red interna y el modelo de amenaza no especifica la penetración de la infraestructura de la red.
En resumen: escribes eso "Si uno de los servidores se ve comprometido, su acceso a la red interna significa que el resto son blancos fáciles.". Esto es cierto,pero no es menos cierto sólo porque la diafonía interna está cifrada.
Cuando le comentas a Ryan arriba de eso "el acceso desde la oficina a la LAN privada alojada se realiza a través de una VPN, y las operaciones en el servicio de producción se realizan desde computadoras portátiles Linux dedicadas en lugar de las máquinas principales de los desarrolladores.", veo una empresa que en realidad espensamientosobre modelos de amenazas y respuestas, en lugar de agitar las criptomonedas como una especie de brillante manta de seguridad y asumir que ahora están a salvo, gracias a las criptomonedas. Parece que trabajan duro para proteger las partes que se benefician de la seguridad y no se preocupan por las que no.
Respuesta2
Tuve una larga conversación sobre esto con un amigo mío. Todo se reduce a lo que estás haciendo y al aspecto de tu red.
Generalmente: es malo.
La criptografía se ha vuelto mucho más sencilla de implementar a lo largo de los años, por lo que no debería haber demasiadas excusas para no implementarla.
Sin embargo, realmente depende de lo que esté pasando por tu cable. ¿Esa información necesita ser confidencial/autenticada? Recuerde que, aunque es posible que el destino no pueda conectarse a Internet, su máquina sí puede hacerlo. Técnicamente, si alguien intervino su máquina o cualquier dispositivo de enrutamiento/conmutación entre usted y su destino, sus datos están comprometidos. Siempre debes asumir que si tu máquina puede acceder a Internet, entonces alguien podría tener todo el poder que tú tienes. El hecho de que Internet no pueda llegar directamente a su LAN privada no significa que no pueda llegar a ella comprometiendo su máquina.
Esto es unfácilmenteTema discutible, pero generalmente no tener cifrado reducirá su postura de seguridad. Si puedes hacerlo, entonces hazlo. Estoy de acuerdo en que su situación tiene un riesgo bastante mínimo, pero aún así, ¡simplemente hágalo!